clases 30 05
TRANSCRIPT
UCLA Rodolfo Canelón
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
UCLA Rodolfo Canelón
Estilos que definen la Arquitectura Sistemas Distribuidos (procesamiento) Cliente/Servidor (física) Repositorio (Datos) O-O Wireless (Comunicación)
UCLA Rodolfo Canelón
Estilo - Cliente/Servidor
2 capas 3 capas n capas Tecnología en el servidor Tecnología en el cliente
UCLA Rodolfo Canelón
El par de entidades que ofrecen y requieren servicios constituye el
modelo cliente/servidor
Client ServerInterface
Estilo - Cliente/Servidor
UCLA Rodolfo Canelón
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
UCLA Rodolfo Canelón
Cliente/Servidor Dos Capas
Maquina Cliente
(UNIX, Windows, Linux,...)
Servidor de Base de Datos
UCLA Rodolfo Canelón
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
UCLA Rodolfo Caneló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/Servidor3 Capas
UCLA Rodolfo Canelón
Interface
GUI
Servidor de datos
Servidor de transacciones
Interface
Capa datos
Capa lógica
Capa presentación
Modelo - Cliente/Servidor3 Capas
UCLA Rodolfo Canelón
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/Servidor3 Capas
UCLA Rodolfo Canelón
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/Servidor3 Capas
UCLA Rodolfo Canelón
Cliente/Servidor Tres capas
Maquina Cliente
(UNIX, Windows, ...)
Maquina Servidor
Servidor de Base de Datos
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
Arquitectura Web n-capas
BDD
Server Applications
TCP/IP, HTTP, HTTPS, Socket, Objetos Distribuidos, CORBA, ORBA
cliente 1 cliente 2 cliente nCapa de
Presentación (1)
Capa de Funcionalidades de la
Aplicación (2)
Repositorio (3)
ODBC, JDBC
CONECTORES:
SQL Net Proxy
n-Capas (4+)
Server Applications Server Applications
BDD
UCLA Rodolfo Canelón
Programas de análisisProgramas de análisis
Aplicaciones y programasmodificados
Reportesy
Análisis
Reportesy
Análisis
MMiiddddlleewwaarree
Bases de datos
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
Enfoque Re-Arquitectura
UCLA Rodolfo Canelón
EJEMPLOBSC
BDD
Server Applications
cliente 1 cliente 2 cliente nCapa de Presentació
n (1)
Capa de Funcionalidades de
la Aplicación (2)
Multi-DB
SQL Net Proxy
Server Applications Server Applications
BDD
Aplicación para Bsc: Entorno PDVSAHeterogeneos, 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 TokenPatrones de Sincronización : Scope Locking C++, Strategized locking
Patrones de Concurrencia : Active Object, Half Async
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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
UCLA Rodolfo Canelón
CALIDAD DELPROCESO
CALIDADINTERNA
CALIDADEXTERNA
CALIDAD ENUSO
INFLUENCIA INFLUENCIA INFLUENCIA
DEPENDE DEPENDEDEPENDE
MEDIDAS DEPROCESO
MEDIDAS INTERNAS
MEDIDASEXTERNAS
MEDIDAS DECALIDAD EN USO
PROCESO PRODUCTO DESOFTWARE
EFECTOS DELPRODUCTO DE
SOFTWARE
CONTEXTOSDE USO
ENFOQUES DE CALIDADISO 9126 (1998))
UCLA Rodolfo Canelón
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
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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?
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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.
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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.
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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.
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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?
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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.
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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.
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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.
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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.
UCLA Rodolfo Canelón
Modelo de Calidad del software
EficienciaConfiabilidad Usabilidad Mantenibilidad PortabilidadFuncionalidad
- 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
UCLA Rodolfo Canelón
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
UCLA Rodolfo Canelón
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
UCLA Rodolfo Canelón
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
UCLA Rodolfo Canelón
RequisitosArquitecturalesREQUISITOS
NO FUNCIONALESPROPIEDADDE CALIDAD
SOLUCIÓNARQUITECTURAL
MÉTRICA
Minimización en el consumo de recursos (baterías, almacenamiento de datos, tamaño del display , entre otros).
Efficiency (performance) Con respecto a la utilización de recursos ; propiedad cuantitativa-Atributo: consumo de recurso para cada dispositivo
Protocolo de comunicación de redes, Ancho de banda. Medida durante la ejecución
Porcentaje [0..1]
Los Datos deben ser transmitidos completa, correctamente y consistentes con conexiones transientes.
Reliability (consistency) Provee un mecanismo, es decir el manejo de la replica actualizando en cada dispositivo; propiedad cualitativa-Atributo: presencia de mecanismo
Middleware incluyendo MEDIATOR Boolean
Tiempo de transmisión limitado. Tiempos de respuesta adecuados a un rango
Efficiency (performance) con respecto al tiempo de respuesta y conexiones; propiedad cuantitativa-Atributo: latency
Protocolo de comunicación de redes, Ancho de banda. Medida durante la ejecución
Porcentaje [0..1]
Comunicación flexible debe ser flexible a los requisitos de cambios y relaciones entre componentes que pueden ser estáticos y dinámicos.
-Maintainability (changeability) Extensibilidad del ambiente de ejecución; propiedad cuantitativa-Atributo: Tamaño -Portability (replaceability)Propiedad cuantitativa -Atributo: Tamaño
Reflection [28]Mecanismo para observar el estado de un componente para permitir cambios dinámicos en la estructura y desempeño
-Medida de complejidad , es decir numero de componentes dinámicos en un periodo de tiempo-Medida de complejidad
Solución centralizada, donde la interfaz del dispositivo es distribuida por el middleware de la aplicación a través de la red.
Reliability (availability) Propiedad cualitativa-Atributo: presencia de un mecanismo, en este caso el middleware soportado por el patrón agente MEDIATOR
Middleware incluyendo MEDIATOR Boolean
Reconfiguracion Dinámica de Interfaces Maintainability (changeability)Propiedad cuantitativa-Atributo: TamañoReliability (consistency)propiedad cualitativa -Atributo: presencia de un mecanismoPortability (adaptability)propiedad cualitativa -Atributo: presencia de un mecanismo
Middleware incluyendo MEDIATOR -Medida de complejidad -Boolean-Boolean
Tabla 3. Requisitos no funcionales, propiedad de calidad y solución arquitectural.
UCLA Rodolfo Canelón
Tabla 4. Propiedades de calidad para cada funcionalidad y su solución arquitectural.
REQUISITOSFUNCIONALES
SOLUCION ARQUITECTURAL
PROPIEDADES DE CALIDAD (INTERNA/EXTERNA)
Manejo de Datos LocalProxy [17]Una instancia local provee una interface a un servicio local o remoto. Ejemplo: Ejecutando localmente un web proxyPushObject [17]Un dispositivo envía un objeto específico con un requisito fuera. Ejemplos : SMS, OBEXRequestObject [17]Un dispositivo requiere un objeto especifico (Una pagina web) desde otro dispositivo. Ejemplo : WAPCannedCode [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
- Realiability (availability, consistency)Atributo: presencia de un mecanismoMétrica: Boolean- Efficiency (performance) con respecto al limitado espacio y al limitado tiempo de respuestaAtributo: consumo de recursos de cada dispositivo Métrica: Porcentaje [0..1]- Maintainability (changeability)Propiedad cuantitativa Atributo: Tamaño
Servicios Centrados al Usuario 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.
- Maintainability (changeability)Atributo: TamañoMé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
Compartimiento de Datos Repository [44] -Reliability (availability, consistency)Atributo: presencia de un mecanismo.Métrica: Boolean
Tabla 4. Propiedades de calidad para cada funcionalidad y su solución arquitectural.
UCLA Rodolfo Canelón
Reglas del negocio asociadas al Dominio Requisitos no funcionales derivados de las reglas del negocio. Propiedades de Calidad asociadas a los requisitos no funcionales(Características de Calidad)
ISO/IEC 9126-1 [15]
Políticas
Uso de protocolos de comunicación de redes, ancho de banda. 1. Cumplir con estándares, normativas con el fin de garantizar el servicio requerido. Funcionalidad (Functionality) - Conformidad (Compliance)
Procesamiento
Los servicios se ejecutan en una diversidad de dispositivos, cada uno con configuraciones y funcionalidades diferentes.
1. Las funcionalidades deben adaptarse a las características de los Dispositivos. Portabilidad (Portability) -Adaptabilidad (adaptability)
Los servicios deben ser garantizados dentro del área de cobertura.
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.
Confiabilidad (confiability) -Disponibilidad (Availability)Eficiencia (eficiency) -Comportamiento del tiempo (Time Behaviour) con respecto al tiempo de respuesta y a las conexiones.
El usuario selecciona los servicios disponibles en el área de cobertura.
1. Ofrecer funcionalidades que respondan a las necesidades de los usuarios.2. Facilidad en la selección de los servicios ofrecidos.
Funcionalidad(Functionality) -Adecuada(Suitability)Usabilidad (usability) -Operabilidad (operability)
Los dispositivos se conecten y desconectan dinámicamente a la red.
1. Garantizar la disponibilidad del servicio al conectarse. Confiabilidad (confiability) -Disponibilidad (availability)
Requisitos No Funcionales APLICACIONES MOVILES
UCLA Rodolfo Canelón
Requisitos Funcionales
Propiedades de calidad asociadas (Características de calidad ) ISO/IEC 9126-1 [15]
Manejar Datos: Los datos deben ser transmitidos completa y correctamente.
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.
Servicios de información: gestiona información al usuario.Usabilidad (Usability) -Atractivo (atractiveness) -Operabilidad (Operability)Portabilidad (Portability) -Adaptabilidad (adaptability) -Escalabilidad (Scalability)
Servicios de comunicación: comunicación entre usuarios, transporte de información y establecimiento de conexiones. Portabilidad (Portability)
-Conformidad (compliance) -Escalabilidad (Scalability)Funcionalidad (Functionability) -Seguridad (Security)
Servicios de administración: (defecto, configuración, Bitácora, ejecución y seguridad)Usabilidad (Usability) -Atractivo (Atractiveness) - Operabilidad (Operability)
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. Confiabilidad (Confiability)
-Disponibilidad (Availability)Funcionalidad (Functionality) -Interoperabilidad (Interoperability)
Requisitos Funcionales APLICACIONES MOVILES
UCLA Rodolfo Canelón
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 protocolo HTTP.
Internet es…Internet es…
…un mecanismo Request/Response.
Workstation
Server
WebPages
Request
Response
HTTP protocol
www.url.com
HTML
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.
UCLA Rodolfo Canelón
Arquitectura para Web
Cliente y Usuario FinalProveedores de ContextoProveedores de ServiciosWhile WorldDesarrollo OrganizacionalProveedores de SoftwareAmbiente TécnicoHeterogéneoComputación DistribuidaWWWExperiencia en ArquitecturasInternet y HipertextoWWW
Requerimientos(Calidad)Acceso RemotoInteroperatibilidadExtensibilidad(de software y datos)EscalabilidadUpward Compatibility
Architect(s)WWW
ConsortiumArquitecturalibWWWJigsawCliente/Servidor
SistemaWWW
Influencias de la Arquitectura
UCLA Rodolfo Canelón
Topología - 1era. GeneraciónZona 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
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
Topología - 3era. Generación
Negocios. Middleware para integradores.
Ventas. Inventario. B2B.
Interfaces de Usuario. Movilidad. Personalización. HIC
UCLA Rodolfo Canelón
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)
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
Topología - 3era. Generación
Zona AbiertaMundo Exterior Red Interna
Cliente
Internet
IP seguro yNo seguro
Páginas Estáticas
Cookie DirectorioSeguridad
Sistemas de Gestión
Cor
tafu
egos
Lig
ero
Nodo de Integración
Aplicación
Aplicación
Aplicación
Nodo de Gestióny Creación de
contenidos
Cor
tafu
egos
del
dom
inio
Servidor de BD
Servidor de información
•Servidor Web•Lógica de Aplicación•Conexiones a Datos•Conexión con Backend.
UCLA Rodolfo Canelón
Estilos que definen la Arquitectura WEB Sistemas Distribuidos (procesamiento) Cliente/Servidor (física) Repositorio O-O Wireless
UCLA Rodolfo Canelón
Estilo – Sistemas Distribuidos
Client-Dispatcher-Server:
Client
doTasksendRequest
Server
acceptConnectingrunService
requests service returns result
Dispatcher
locationMapregisterService
unregisterServicelocateServer
establishChannelgetChannel
requests connection receiveRequest
registers
accepts linkestablishes
connection
UCLA Rodolfo Canelón
Estilo – Sistemas Distribuidos
Broker para comunicación directa:
Registry(Broker)
Objetos distribuidos
Client-side
WWW browser(Client)
Object server
Other WWWservers
WWW server
RMI
URL
URLRMIRMI
URL
Server-side
UCLA Rodolfo Canelón
Estilo - Cliente/Servidor
2 capas 3 capas n capas Tecnología en el servidor Tecnología en el cliente
UCLA Rodolfo Canelón
Arquitectura Web n-capas
BDD
Server Applications
TCP/IP, HTTP, HTTPS, Socket, Objetos Distribuidos, CORBA, ORBA
cliente 1 cliente 2 cliente nCapa de
Presentación (1)
Capa de Funcionalidades de la
Aplicación (2)
Repositorio (3)
ODBC, JDBC
CONECTORES:
SQL Net Proxy
n-Capas (4+)
Server Applications Server Applications
BDD
UCLA Rodolfo Canelón
EJEMPLOBSC
BDD
Server Applications
cliente 1 cliente 2 cliente nCapa de Presentació
n (1)
Capa de Funcionalidades de
la Aplicación (2)
Multi-DB
SQL Net Proxy
Server Applications Server Applications
BDD
Aplicación para Bsc: Entorno PDVSAHeterogeneos, 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 TokenPatrones de Sincronización : Scope Locking C++, Strategized locking
Patrones de Concurrencia : Active Object, Half Async
UCLA Rodolfo Canelón
Tecnología en el Servidor
CGI: Shell, Perl, C. API´s Web Propietarias: ISAPI, NSAPI. ASP. PHP. Java Script. JSP JSP (Servlets). MIDLETS
UCLA Rodolfo Canelón
Tecnología de Clientes: Etiquetas:
SMG. HTML. Script. Applets. Thin/Fat.
XLETS
Tecnología en el Cliente
UCLA Rodolfo Canelón
Atributos presentes en la Arquitectura WEB1. Acceso Remoto
2. Interoperatibidad
3. Extensibilidad
4. Escalabilidad
5. Evolutiva
6. Reflexiva
7. Adaptable y Configurable
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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?
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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.
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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.
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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?
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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.
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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.
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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.
UCLA Rodolfo Canelón
Calidad de SoftwareAtributos 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.
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
Calidad de Software en WEB(Modelo de Calidad ISO-9126-1)
CARACTERISTICAS DE CALIDAD
SUB-CARACTERISTICAS
MODELO DE CALIDAD PARA APLICACIONES WEB: VISION EXTERNA
FUNCIONALIDAD
CONVENIENCIA EXACTITUD INTEROPERABILIDAD
SEGURIDAD
CONFIABILIDAD
MADUREZ
ATRACTIVIDAD OPERATIVIDAD
USABILIDAD
ENTENDIBILIDAD APRENDIZAJE
EFICIENCIA
COMPORTAMIENTO EN EL TIEMPO
UTILIZACION DE RECURSOS
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Caneló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.
UCLA Rodolfo Canelón
Calidad de Software en WEB(Modelo de Calidad ISO-9126-1)
CARACTERISTICAS DE CALIDAD
SUB-CARACTERISTICAS
MANTENIBILIDAD
ANALIZABILIDAD CAMBIABILIDAD
PORTABILIDAD
ADAPTABILIDAD INSTALABILIDAD
MODELO DE CALIDAD PARA APLICACIONES WEB: VISION INTERNA
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
Calidad de Software en WEB(Modelo de Calidad ISO-9126-1)
Actividades a realizar para evaluar las arquitecturas propuestas:
1. Análisis de los requerimientos funcionales y no funcionales del sistema para establecer las metas de calidad.
2. Dar prioridad a las subcaracterísticas de calidad tomando en cuenta los requerimientos de calidad del sistema.
3. Presentación de los estilos arquitectónicos a utilizarse para definir la arquitectura.
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
Calidad de Software en WEB(Modelo de Calidad ISO-9126-1)
Características Sub-Características Capas Repositorio O-O Conveniencia (Suitability)
Si Si Si
Interoperatibilidad Si Si No
Funcionalidad
Seguridad Mecanismos a nivel de protocolo y socket
Mecanismo por cada requerimiento del cliente
Mecanismos a nivel de pase de mensajes
Madurez Protocolo + Socket
Alta
Tolerancia a Fallas No Depende de meca-nismos adicionales
No
Confiabilidad
Recuperabilidad Depende de meca-nismos adicionales
Depende de meca-nismos adicionales
No
Comportamiento en el tiempo
Velocidad de respuesta de la capa
Depende del tiempo de respuesta del DataServer
Depende del tiem-po de respuesta del mensaje
Eficiencia
Utilización de recursos
Mensaje de: solicitud y respuesta
Invocaciones a la base de datos
Paso de mensajes
UCLA Rodolfo Canelón
Calidad de Software en WEB(Modelo de Calidad ISO-9126-1)
Características Sub-Características Capas Repositorio O-O Analizabilidad Si Depende de meca-
nismos adicionales. Depende de meca-nismos adicionales.
Cambiabilidad Si Depende de meca-nismos adicionales.
Depende de meca-nismos adicionales.
Estabilidad Si Depende de meca-nismos adicionales.
Depende de meca-nismos adicionales.
Evaluabilidad Si Depende de meca-nismos adicionales.
Depende de meca-nismos adicionales.
Acoplamiento Bajo Depende de meca-nismos adicionales.
Depende de meca-nismos adicionales.
Mantenibilidad
Modularidad Si Depende de meca-nismos adicionales.
Depende de meca-nismos adicionales.
Portabilidad Adaptabilidad Si Depende de meca-nismos adicionales.
Depende de meca-nismos adicionales.
Instalabilidad Si Depende de meca-nismos adicionales.
Depende de meca-nismos adicionales.
Reemplazabilidad Si Depende de meca-nismos adicionales.
Depende de meca-nismos adicionales.
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
CLASES Siguen …
OctubreMiddleware Protocolos EAI NoviembreCaracterizaciónArquitecturaPatronesFrameworkConstrucción de la interfaz
UCLA Rodolfo Canelón
Patrones de Aplicaciones WEB
Rodolfo CanelónRodolfo Canelón
UCLA 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)
UCLA Rodolfo Canelón
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
UCLA Rodolfo Canelón
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)
UCLA Rodolfo Canelón
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)
(Cte): Componente (Ctor): Conector
Thin Web Client (Cliente Web Ligero)
UCLA Rodolfo Canelón
• Vista lógica mínima del patrón
Browser HTTPServidor 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 Thin Web Client (Cliente Web Ligero)(Cliente Web Ligero)
UCLA Rodolfo Canelón
Elementos Opcionales Persistencia
Sistemas de Bases de Datos, etc.
Integración con sistemas heredados Sistemas Legacy, Sistemas Administrativos, etc.
Thin Web Client (Cliente Web Ligero)
UCLA Rodolfo Canelón
BrowserHTTP Servidor Web Servidor de Aplicaciones
Páginas del ServidorPáginas HTML
Objetos delNegocio
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 ClientThin Web Client (Cliente Web Ligero)(Cliente Web Ligero)
• Vista lógica completa del patrón
UCLA Rodolfo Canelón
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
Thin Web Client (Cliente Web Ligero)
UCLA Rodolfo Canelón
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)
UCLA Rodolfo Canelón
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
Fat Web Client (Cliente Web Pesado)
UCLA Rodolfo Canelón
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 ClientFat Web Client (Cliente Web Pesado)(Cliente Web Pesado)
UCLA Rodolfo Canelón
HTTP
Objetos delNegocio
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
ControlActiveX
Applet Java
Script del Cliente
Fat Web ClientFat Web Client (Cliente Web Pesado)(Cliente Web Pesado)
• Vista lógica del patrón
UCLA Rodolfo Canelón
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 Fat Web Client (Cliente Web Pesado)(Cliente Web Pesado)
UCLA Rodolfo Canelón
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
Web Delivery (Distribución Web)
UCLA Rodolfo Canelón
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 Web Delivery (Distribución Web)(Distribución Web)
UCLA Rodolfo Canelón
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 Web Delivery (Distribución Web)(Distribución Web)
UCLA Rodolfo Canelón
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 Web Delivery (Distribución Web)(Distribución Web)
UCLA Rodolfo Canelón
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, conobjetos del servidor
Web Delivery Web Delivery (Distribución Web)(Distribución Web)
UCLA Rodolfo Canelón
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 Web Delivery (Distribución Web)(Distribución Web)
UCLA Rodolfo Canelón
Web Delivery Web Delivery (Distribución Web)(Distribución Web)
• Vista lógica del patrón
Objetos delNegocio
PersistenciaMapping de Persistencia
Sist. Contabilidad de Mercado
Interfaz de Sistema Heredado
Páginas del Servidor
Páginas HTML
Servidor de Aplicaciones
Servidor Web
Browser
ActiveX delServidor
ActiveX delCliente
Applet Java
DCOM RMIHttp, Https,CORBA
IIOP
Enterprise JavaBeans
UCLA Rodolfo Canelón
Patrones Arquitectónicos en WebEjemplo
BDD
Server Applications
cliente 1 cliente 2 cliente nCapa de Presentació
n (1)
Capa de Funcionalidades de
la Aplicación (2)
Multi-DB
SQL Net Proxy
Server Applications Server Applications
BDD
Aplicación para Bsc: Entorno PDVSAHeterogeneos, 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 TokenPatrones de Sincronización : Scope Locking C++, Strategized locking
Patrones de Concurrencia : Active Object, Half Async
UCLA Rodolfo Canelón
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
UCLA Rodolfo Canelón
Patrones Arquitectónicos en Web(para Acceso y Configuración de Servicio)
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.
Microkernel o Socket
Reflection
Wrapper Façade
Component Configurator
Interceptor
Extension Interface
Multi-DataBase
UCLA Rodolfo Canelón
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 Configuración de Servicio)
Microkernel o Socket
Reflection
Wrapper Façade
Component Configurator
Interceptor
Extension Interface
Multi-DataBase
UCLA Rodolfo Canelón
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).
UCLA Rodolfo Caneló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 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).
UCLA Rodolfo Caneló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 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).
UCLA Rodolfo Caneló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).
UCLA Rodolfo Caneló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).
UCLA Rodolfo Canelón
Patrones Arquitectónicos en Web
Reactor
Asynchronous Completion Token
Patrones para Manejo de Eventos
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
Patrones Arquitectónicos en Web
Strategized Locking
Thread-Safe Interface
Patrones para Sincronización
UCLA Rodolfo Caneló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).
UCLA Rodolfo Canelón
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).
UCLA Rodolfo Canelón
Patrones Arquitectónicos en Web
Active Object
Monitor Objects
Half Sync / Half Async
Patrones de Concurrencia
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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).
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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
UCLA Rodolfo Canelón
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.
UCLA Rodolfo Canelón
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
ProcesadoresDisponibles
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/ODisponibles
RecursosInteracción
Tiene_Asociado
1..*
Tienen
1..*
Usa Se_Adaptan
Ambiente Computacional1..*
Modelo Conceptual APLICACIONES MOVILES
UCLA Rodolfo Canelón
Componentes de las aplicaciones
Servicios y Aplicaciones GUI /Client Side MIDDLEWARE
Seguridad )
)
)
Figura 2-5. Componentes de las aplicaciones
UCLA Rodolfo Canelón
Servicios y Aplicaciones GUI cliente Contexto
Seguridad )
)
)
Figura 2-5. Componentes de las aplicaciones
Mediator )
Componentes de las aplicaciones
UCLA Rodolfo Canelón
Reglas del negocio asociadas al Dominio Requisitos no funcionales derivados de las reglas del negocio. Propiedades de Calidad asociadas a los requisitos no funcionales(Características de Calidad)
ISO/IEC 9126-1 [15]
Políticas
Uso de protocolos de comunicación de redes, ancho de banda. 1. Cumplir con estándares, normativas con el fin de garantizar el servicio requerido. Funcionalidad (Functionality) - Conformidad (Compliance)
Procesamiento
Los servicios se ejecutan en una diversidad de dispositivos, cada uno con configuraciones y funcionalidades diferentes.
1. Las funcionalidades deben adaptarse a las características de los Dispositivos. Portabilidad (Portability) -Adaptabilidad (adaptability)
Los servicios deben ser garantizados dentro del área de cobertura.
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.
Confiabilidad (confiability) -Disponibilidad (Availability)Eficiencia (eficiency) -Comportamiento del tiempo (Time Behaviour) con respecto al tiempo de respuesta y a las conexiones.
El usuario selecciona los servicios disponibles en el área de cobertura.
1. Ofrecer funcionalidades que respondan a las necesidades de los usuarios.2. Facilidad en la selección de los servicios ofrecidos.
Funcionalidad(Functionality) -Adecuada(Suitability)Usabilidad (usability) -Operabilidad (operability)
Los dispositivos se conecten y desconectan dinámicamente a la red.
1. Garantizar la disponibilidad del servicio al conectarse. Confiabilidad (confiability) -Disponibilidad (availability)
Requisitos No Funcionales APLICACIONES MOVILES
UCLA Rodolfo Canelón
Requisitos Funcionales
Propiedades de calidad asociadas (Características de calidad ) ISO/IEC 9126-1 [15]
Manejar Datos: Los datos deben ser transmitidos completa y correctamente.
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.
Servicios de información: gestiona información al usuario.Usabilidad (Usability) -Atractivo (atractiveness) -Operabilidad (Operability)Portabilidad (Portability) -Adaptabilidad (adaptability) -Escalabilidad (Scalability)
Servicios de comunicación: comunicación entre usuarios, transporte de información y establecimiento de conexiones. Portabilidad (Portability)
-Conformidad (compliance) -Escalabilidad (Scalability)Funcionalidad (Functionability) -Seguridad (Security)
Servicios de administración: (defecto, configuración, Bitácora, ejecución y seguridad)Usabilidad (Usability) -Atractivo (Atractiveness) - Operabilidad (Operability)
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. Confiabilidad (Confiability)
-Disponibilidad (Availability)Funcionalidad (Functionality) -Interoperabilidad (Interoperability)
Requisitos Funcionales APLICACIONES MOVILES
UCLA Rodolfo Canelón
Patrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
Grupo multidisciplinario de desarrollo
DiseñadorGráfico
Psicólogo
Especialistasen IHC
Especialistasen 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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
¿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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
Guías de Diseño
Los principios son conceptos de alto Los principios son conceptos de alto nivel que orientan la actividad del nivel que orientan la actividad del diseño de la interfazdiseño de la interfaz
Los lineamientos son reglas que se Los lineamientos son reglas que se establecen en una organización para el establecen en una organización para el diseño y desarrollo de interfaces diseño y desarrollo de interfaces referentes al look and feelreferentes al look and feel
Patrones de Interacción MóvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
Antecedentes
90’s Patrones en ComputaciónPatrones en Computación
Patrones en IHC
Patrones de interacción como una herramienta apropiada para la captura y reutilización de las experiencias y conocimientos de los expertos
Patrones de Interacción MóvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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.
Un patrón de interfaz sirve para:
Patrones de Diseño
Patrones de Interacción MóvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
Estructura de un Patrón de Interfaz
Nombre,clasificación,confianza yautor
El nombre comunica la idea centralLa clasificación indica tipo de patrónLa confianza es, según el autor, la madurez delpatrónEl autor del patrón
Problema Problema que resuelve este patrón
Solución Solución que ha mostrado tener éxito en estecontexto
Contexto Condición(es) en la(s) cual(es) se puede usar elpatrón.
Fuerzas Los conflictos que pueden restringir la solución
Usabilidad Describe el impacto de usabilidad en la interfaz alaplicar el patrón.
Consecuencias Describe los resultados de aplicar el patrón.
Ejemplos y /oContraejemplos
Muestras de soluciones exitosas y/o de un mal usodel patrón.
PatronesRelacionados
Otros patrones con los que está relacionado estepatrón
Patrones de Interacción MóvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
Ejemplo de un Patrón de Interacción
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
Jerarquía de Patrones
Patrones de Interacción MóvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
Descripción de Patrones de Diseño MóvilesPara 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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
Estructura de un Patrón Móvil
Nombre El nombre comunica la idea centralSinopsis Problema que resuelve este patrón
ContextoCondición(es) en la(s) cual(es) se puede usar el patrón.
FuerzaLos conflictos que pueden restringir la solución
SoluciónSolución que ha mostrado tener éxoto en este contexto.
Consecuencias Describe los resultados de aplicar el patrón
Ejemplos Muestra de soluciones exitosas y/o de un mal uso del patrón
Patrones Relacionados
Otros patrones con los que está relacionado este patrón
ClasesDan información adicional de la estructura a un diseñador
Patrones de Interacción MóvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
Proxy - Patrón Móvil de Interacción
SINOPSIS 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.
CONTEXTO 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.
FUERZAS 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 localEspera apropiadas I/O acorde a las capacidades locales disponibles.
Patrones de Interacción MóvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
SOLUCION 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 dispositivoConecta al actual proveedor de servicio y ejecuta el requerimientoProcesa los resultados Envía de regreso al dispositivo inicial
Proxy - Patrón Móvil de Interacción
Patrones de Interacción MóvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
CONSECUENCIAS 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 redEl 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
Proxy - Patrón Móvil de Interacción
Patrones de Interacción MóvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
EJEMPLOS 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.
PATRONES RELACIONADOS
PushObject, RequestObject
CLASES ServiceUsage, MobileService
Proxy - Patrón Móvil de Interacción
Patrones de Interacción MóvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
Proxy - Estructura
...
Subject
Request( )
Proxy
Request( )
Real Subject
Request( ) Real Subject
...
Patrones de Interacción MóvilPatrones de Interacción Móvil
Client
…….
UCLA Rodolfo Canelón
DocumentEditor
Graphic
ImageProxy
ImageDraw()
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
Editor de documentos (Ej.)
Patrones de Interacción MóvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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óvilPatrones de Interacción Móvil
UCLA Rodolfo Canelón
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), 2001Tim 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óvilPatrones de Interacción Móvil