clases 30 05

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


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 ServerInterface



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



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/Servidor3 Capas


Interface

GUI

Servidor de datos

Servidor de transacciones

Interface

Capa datos

Capa lógica

Capa presentació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



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



Cliente/Servidor Tres capas

Maquina Cliente

(UNIX, Windows, ...)

Maquina Servidor

Servidor de Base de Datos



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

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


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


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


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


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 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))


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 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?



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.



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.



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 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?


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.



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.



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.



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

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


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



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.


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.


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


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.


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


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


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 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 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 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:

Client

doTasksendRequest

Server

acceptConnectingrunService

requests service returns result

Dispatcher

locationMapregisterService

unregisterServicelocateServer

establishChannelgetChannel

requests connection receiveRequest

registers

accepts linkestablishes

connection


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



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

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+)


BDD


EJEMPLOBSC

BDD

Server Applications


n (1)


la Aplicación (2)

Multi-DB

SQL Net Proxy


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 WEB1. 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.



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.



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?



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.



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



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 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?



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.



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.



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 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.



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.



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



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.



Visión externa: Usabilidad: Capacidad de la aplicación Web de ser aprendida, entendida, utilizada y ser atractiva a sus usuarios.


• 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.



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.



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.


• 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.



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



Visión interna:Mantenibilidad: Conjunto de atributos relacionados con el esfuerzo necesario para realizar modificaciones en una aplicación Web..


• 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.



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.



Visión interna:Portabilidad: Atributos de la aplicación Web que permiten su transferencia de una plataforma a otra.


• 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.



CARACTERISTICAS DE CALIDAD

SUB-CARACTERISTICAS

MANTENIBILIDAD

ANALIZABILIDAD CAMBIABILIDAD

PORTABILIDAD

ADAPTABILIDAD INSTALABILIDAD

MODELO DE CALIDAD PARA APLICACIONES WEB: VISION INTERNA



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.



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.



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.



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



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.


Evaluabilidad Si Depende de meca-nismos adicionales.


Acoplamiento Bajo Depende de meca-nismos adicionales.


Mantenibilidad

Modularidad Si Depende de meca-nismos adicionales.


Portabilidad Adaptabilidad Si Depende de meca-nismos adicionales.


Instalabilidad Si Depende de meca-nismos adicionales.


Reemplazabilidad Si Depende de meca-nismos adicionales.



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 …

OctubreMiddleware Protocolos EAI NoviembreCaracterizaciónArquitecturaPatronesFrameworkConstrucción de la interfaz


Patrones de Aplicaciones WEB

Rodolfo CanelónRodolfo 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)

(Cte): Componente (Ctor): Conector



• 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)


Elementos Opcionales Persistencia

Sistemas de Bases de Datos, etc.

Integración con sistemas heredados Sistemas Legacy, Sistemas Administrativos, etc.



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


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



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

Fat Web Client (Cliente Web Pesado)


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)


HTTP

Objetos delNegocio

Persistencia

Mapping de Persistencia

Sistema de Contabilidad de Mercado



+ Active SP+ Java SP + Java Servlets+ ISAPI+ NSAPI+ CGI

Páginas HTML

+ Form+ Elementos de Entrada


+ 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


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)


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)


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)


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



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)



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



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




• Vista lógica del patrón

Objetos delNegocio

PersistenciaMapping de Persistencia

Sist. Contabilidad de Mercado



Páginas HTML


Servidor Web

Browser

ActiveX delServidor

ActiveX delCliente

Applet Java

DCOM RMIHttp, Https,CORBA

IIOP

Enterprise JavaBeans


Patrones Arquitectónicos en WebEjemplo

BDD

Server Applications


n (1)


la Aplicación (2)

Multi-DB

SQL Net Proxy


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)

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


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 Configuración de Servicio)


Reflection

Wrapper Façade


Interceptor

Extension Interface

Multi-DataBase


Patrones Arquitectónicos en Web (para Acceso y Configuracion de Servicio)


Reflection

Wrapper Façade


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)


Reflection

Wrapper Façade


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).




Reflection

Wrapper Façade


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).




Reflection

Wrapper Façade


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).




Reflection

Wrapper Façade


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


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


Permite a una aplicación multiplexar eficientemente las respuestas de operaciones asíncronas entre un proceso y un servicio.

Favorece la mantenibilidad.



Strategized Locking

Thread-Safe Interface

Patrones para Sincronización


Patrones Arquitectónicos en Web (para Sincronización)

Strategized Locking


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


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).



Active Object

Monitor Objects

Half Sync / Half Async

Patrones de Concurrencia


Patrones Arquitectónicos en Web (para Concurrencia)

Active Object

Monitor Objects


Sincroniza los accesos al objeto activo dentro del propio threads de control.

Favorece la mantenibilidad, la extensibilidad, la adaptabilidad.



Active Object

Monitor Objects


Asegura la sincronización a un único método a la vez en runtime.

Favorece la mantenibilidad (para testing).



Active Object

Monitor Objects


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.


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


Componentes de las aplicaciones

Servicios y Aplicaciones GUI /Client Side MIDDLEWARE

Seguridad )

)

)

Figura 2-5. Componentes de las aplicaciones


Servicios y Aplicaciones GUI cliente Contexto

Seguridad )

)

)

Figura 2-5. Componentes de las aplicaciones

Mediator )

Componentes de las aplicaciones


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


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óvilPatrones 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



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



¿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.



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



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...)



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



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



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



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).



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



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ó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



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



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 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.



Jerarquía de Patrones



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



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



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



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.



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.



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




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




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 - Estructura

...

Subject

Request( )

Proxy

Request( )

Real Subject

Request( ) Real Subject

...


Client

…….


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.)



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.



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.



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.



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


clases 30 05

Education