14. Arquitectura Web n-capas BDD Server Applications TCP/IP, HTTP, HTTPS, Socket, Objetos Distribuidos, CORBA, ORBA Capa de Funcionalidades de la Aplicación (2) Repositorio (3) ODBC, JDBC CONECTORES: Proxy n-Capas (4+) Server Applications Server Applications BDD cliente 1 cliente 2 cliente n Capa de Presentación (1) SQL Net
15.
16.
17.
18.
19.
20.
21. CALIDAD DEL PROCESO CALIDAD INTERNA CALIDAD EXTERNA CALIDAD EN USO INFLUENCIA INFLUENCIA INFLUENCIA DEPENDE DEPENDE DEPENDE MEDIDAS DE PROCESO MEDIDAS INTERNAS MEDIDAS EXTERNAS MEDIDAS DE CALIDAD EN USO PROCESO PRODUCTO DE SOFTWARE EFECTOS DEL PRODUCTO DE SOFTWARE CONTEXTOS DE USO ENFOQUES DE CALIDAD ISO 9126 (1998) )
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32. Modelo de Calidad del software Eficiencia Confiabilidad Usabilidad Mantenibilidad Portabilidad Funcionalidad - Convenienza - Correctitud - Interoperativ. - Seguridad - Conformidad - Madurez - Tol. Fallas - Recuperab. -Conformidad - Entendibilidad - Aprendibilidad - Operatividad - Atracción - Conformidad - Comporta- miento en tiempo - Uso de recursos - Conformidad Modelo de calidad según ISO 9126 (Calidad externa e interna) - Analizabilidad - Flexibilidad a cambios - Estabilidad - Prueba - Conformidad - Adaptabilidad - Inestabilidad - Co-existencia - Reemplaza- bilidad - Conformidad
33.
34.
35.
36. RequisitosArquitecturales Tabla 3. Requisitos no funcionales , propiedad de calidad y solución arquitectural. -Medida de complejidad -Boolean -Boolean Middleware incluyendo MEDIATOR Maintainability (changeability) Propiedad cuantitativa -Atributo: Tamaño Reliability (consistency) propiedad cualitativa - Atributo: presencia de un mecanismo Portability (adaptability) propiedad cualitativa - Atributo: presencia de un mecanismo Reconfiguracion Dinámica de Interfaces Boolean Middleware incluyendo MEDIATOR Reliability (availability ) Propiedad cualitativa -Atributo: presencia de un mecanismo, en este caso el middleware soportado por el patrón agente MEDIATOR Solución centralizada, donde la interfaz del dispositivo es distribuida por el middleware de la aplicación a través de la red. -Medida de complejidad , es decir numero de componentes dinámicos en un periodo de tiempo -Medida de complejidad Reflection [28] Mecanismo para observar el estado de un componente para permitir cambios dinámicos en la estructura y desempeño -Maintainability ( changeability) Extensibilidad del ambiente de ejecución; propiedad cuantitativa -Atributo: Tamaño -Portability (replaceability) Propiedad cuantitativa -Atributo: Tamaño Comunicación flexible debe ser flexible a los requisitos de cambios y relaciones entre componentes que pueden ser estáticos y dinámicos. Porcentaje [0..1] Protocolo de comunicación de redes, Ancho de banda. Medida durante la ejecución Efficiency (performance ) con respecto al tiempo de respuesta y conexiones; propiedad cuantitativa -Atributo: latency Tiempo de transmisión limitado. Tiempos de respuesta adecuados a un rango Boolean Middleware incluyendo MEDIATOR Reliability (consistency) Provee un mecanismo, es decir el manejo de la replica actualizando en cada dispositivo; propiedad cualitativa -Atributo: presencia de mecanismo Los Datos deben ser transmitidos completa, correctamente y consistentes con conexiones transientes. Porcentaje [0..1] Protocolo de comunicación de redes, Ancho de banda. Medida durante la ejecución Efficiency (performance) Con respecto a la utilización de recursos ; propiedad cuantitativa -Atributo: consumo de recurso para cada dispositivo Minimización en el consumo de recursos (baterías, almacenamiento de datos, tamaño del display , entre otros). MÉTRICA SOLUCIÓN ARQUITECTURAL PROPIEDAD DE CALIDAD REQUISITOS NO FUNCIONALES
37. Tabla 4. Propiedades de calidad para cada funcionalidad y su solución arquitectural. Tabla 4. Propiedades de calidad para cada funcionalidad y su solución arquitectural. - Reliability (availability, consistency) Atributo: presencia de un mecanismo. Métrica : Boolean Repository [44] Compartimiento de Datos - Maintainability (changeability) Atributo: Tamaño Métrica: Medida de complejidad - Reliability (fault-tolerance) Atributo: presencia de un mecanismo. Métrica : Boolean -Usability (attractiveness, operability) Atributo: presencia de un mecanismo. Metrica: Boolean WrapperFaçade [28] Encapsula funciones y datos de no orientados a objetos en APIs concisas, portables, mantenibles y robustas interfaces de clases ComponentConfigurator [28] Permite al componente reconfigurarse en tiempo de ejecución vaciando, modificando, recompilando o encadenando estáticamente la aplicación. Interceptor [28] Permite transparentemente adicionar servicios cuando ciertos eventos ocurran. Variantes : Chain-of-responsibility, Publisher/subscriber y Subject/observer. Extension Interface [28] Permite exportar múltiples interfaces por un componente. El componente funcionalmente es extendido y modificado. Servicios Centrados al Usuario - Realiability (availability, consistency) Atributo: presencia de un mecanismo Métrica: Boolean - Efficiency (performance) con respecto al limitado espacio y al limitado tiempo de respuesta Atributo: consumo de recursos de cada dispositivo Métrica: Porcentaje [0..1] - Maintainability (changeability) Propiedad cuantitativa Atributo : Tamaño LocalProxy [17] Una instancia local provee una interfac e a un servicio local o remoto. Ejemplo : Ejecutando localmente un web proxy PushObject [17] Un dispositivo envía un objeto específico con un requisito fuera. Ejemplos : SMS, OBEX RequestObject [17] Un dispositivo requiere un objeto especifico (Una pagina web ) desde otro dispositivo. Ejemplo : WAP CannedCode [17] Un dispositivo envía código, el cual es ejecutado sobre otro dispositivo. El código no debe ser ejecutado sobre el dispositivo que envió. Ejemplo : WMLscript, web filters Manejo de Datos PROPIEDADES DE CALIDAD (INTERNA/EXTERNA) SOLUCION ARQUITECTURAL REQUISITOS FUNCIONALES
38.
39. Requisitos Funcionales APLICACIONES MOVILES Confiabilidad (Confiability) -Disponibilidad (Availability) Funcionalidad (Functionality) -Interoperabilidad (Interoperability) Compartir Datos: Los dispositivos móviles formarán una red ad-hoc que se conecta entre ellos para intercambiar la información y para proporcionar los servicios a los usuarios. Usabilidad (Usability) -Atractivo (Atractiveness) - Operabilidad (Operability) Servicios de administración: (defecto, configuración, Bitácora, ejecución y seguridad) Portabilidad (Portability) -Conformidad (compliance) -Escalabilidad (Scalability) Funcionalidad (Functionability) -Seguridad (Security) Servicios de comunicación: comunicación entre usuarios, transporte de información y establecimiento de conexiones. Usabilidad (Usability) -Atractivo (atractiveness) -Operabilidad (Operability) Portabilidad (Portability) -Adaptabilidad (adaptability) -Escalabilidad (Scalability) Servicios de información: gestiona información al usuario. Confiabilidad (confiability) -Disponibilidad (availability) Con respecto a lo limitado del recurso de espacio) Eficiencia (Efficiency) -Comportamiento del tiempo (Behaviour time) (con respecto al tiempo de respuesta limitado). Funcionalidad (Functionality) - Precisión (accurancy) En el estándar QoS ISO [17], la integridad esta relacionada con acurrancy. Manejar Datos: Los datos deben ser transmitidos completa y correctamente. Propiedades de calidad asociadas (Características de calidad ) ISO/IEC 9126-1 [15] Requisitos Funcionales
40. Topología de aplicaciones WEB. Caso De Estudio Desde un web browser, un usuario indica un URL. Este es un request a un server remoto sobre el p rotocolo HTTP. Internet es… … un mecanismo Request/Response . Workstation Server Web Pages HTTP protocol www.url.com HTML Request Response El server remoto procesa el request y envia un HTML response que es recibido por el browser y presentado al usuario como una pagina WEB.
41. Arquitectura para Web Cliente y Usuario Final Proveedores de Contexto Proveedores de Servicios While World Desarrollo Organizacional Proveedores de Software Ambiente Técnico Heterogéneo Computación Distribuida WWW Experiencia en Arquitecturas Internet y Hipertexto WWW Requerimientos (Calidad) Acceso Remoto Interoperatibilidad Extensibilidad (de software y datos) Escalabilidad Upward Compatibility Architect(s) WWW Consortium Arquitectura libWWW Jigsaw Cliente/Servidor Sistema WWW Influencias de la Arquitectura
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55. Arquitectura Web n-capas BDD Server Applications TCP/IP, HTTP, HTTPS, Socket, Objetos Distribuidos, CORBA, ORBA Capa de Funcionalidades de la Aplicación (2) Repositorio (3) ODBC, JDBC CONECTORES: Proxy n-Capas (4+) Server Applications Server Applications BDD cliente 1 cliente 2 cliente n Capa de Presentación (1) SQL Net
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78. Calidad de Software en WEB (Modelo de Calidad ISO-9126-1) MODELO DE CALIDAD PARA APLICACIONES WEB: VISION EXTERNA CARACTERISTICAS DE CALIDAD SUB-CARACTERISTICAS FUNCIONALIDAD CONVENIENCIA EXACTITUD INTEROPERABILIDAD SEGURIDAD CONFIABILIDAD MADUREZ ATRACTIVIDAD OPERATIVIDAD USABILIDAD ENTENDIBILIDAD APRENDIZAJE EFICIENCIA COMPORTAMIENTO EN EL TIEMPO UTILIZACION DE RECURSOS
79.
80.
81.
82. Calidad de Software en WEB (Modelo de Calidad ISO-9126-1) MODELO DE CALIDAD PARA APLICACIONES WEB: VISION INTERNA CARACTERISTICAS DE CALIDAD SUB-CARACTERISTICAS MANTENIBILIDAD ANALIZABILIDAD CAMBIABILIDAD PORTABILIDAD ADAPTABILIDAD INSTALABILIDAD
133. Modelo Conceptual APLICACIONES MOVILES Servicios Dispositivos móviles Teléfonos inteligentes Pad´s Otros Handhelp Contexto Conectividad Red Usuario Comunicación Administración Información Funciones del dispositivo Ambiente Físico Procesadores Disponibles Tiene_asociado_Un 1..* Se_Ejecutan 1..* 1..* QoS Funciones del Usuario 1..* Influye_en Ambiente del usuario Localización Perfil Iluminación Nivel de ruido Dispositivos I/O Disponibles Recursos Interacción Tiene_Asociado 1..* Tienen 1..* Usa Se_Adaptan Ambiente Computacional 1..*
134. Componentes de las aplicaciones Servicios y Aplicaciones GUI /Client Side MIDDLEWARE Seguridad ) ) ) Figura 2-5. Componentes de las aplicaciones
135. Componentes de las aplicaciones Servicios y Aplicaciones GUI cliente Contexto Seguridad ) ) ) Figura 2-5. Componentes de las aplicaciones Mediator )
136.
137. Requisitos Funcionales APLICACIONES MOVILES Confiabilidad (Confiability) -Disponibilidad (Availability) Funcionalidad (Functionality) -Interoperabilidad (Interoperability) Compartir Datos: Los dispositivos móviles formarán una red ad-hoc que se conecta entre ellos para intercambiar la información y para proporcionar los servicios a los usuarios. Usabilidad (Usability) -Atractivo (Atractiveness) - Operabilidad (Operability) Servicios de administración: (defecto, configuración, Bitácora, ejecución y seguridad) Portabilidad (Portability) -Conformidad (compliance) -Escalabilidad (Scalability) Funcionalidad (Functionability) -Seguridad (Security) Servicios de comunicación: comunicación entre usuarios, transporte de información y establecimiento de conexiones. Usabilidad (Usability) -Atractivo (atractiveness) -Operabilidad (Operability) Portabilidad (Portability) -Adaptabilidad (adaptability) -Escalabilidad (Scalability) Servicios de información: gestiona información al usuario. Confiabilidad (confiability) -Disponibilidad (availability) Con respecto a lo limitado del recurso de espacio) Eficiencia (Efficiency) -Comportamiento del tiempo (Behaviour time) (con respecto al tiempo de respuesta limitado). Funcionalidad (Functionality) - Precisión (accurancy) En el estándar QoS ISO [17], la integridad esta relacionada con acurrancy. Manejar Datos: Los datos deben ser transmitidos completa y correctamente. Propiedades de calidad asociadas (Características de calidad ) ISO/IEC 9126-1 [15] Requisitos Funcionales
139. Problemas en la construcción de interfaces 1.- Dificultad para construir software usable 2.- Se desestima la necesidad de un grupo de desarrollo multidisciplinario 3.- Problemas de comunicación entre los miembros de un grupo multidisciplinario 4.- En la práctica no se reconoce la relevancia del usuario 5.- Falta de integración entre la Interacción Humano-Computador y la Ingeniería de Software. Patrones de Interacción Móvil
140.
141. Grupo multidisciplinario de desarrollo Diseñador Gráfico Psicólogo Especialistas en IHC Especialistas en el dominio Usuario ... Para el diseño de Interfaces de Usuario se requiere un equipo que incluya al usuario, especialistas del dominio de la aplicación y a especialistas de otras disciplinas Patrones de Interacción Móvil
142.
143.
144.
145.
146.
147.
148.
149. Estructura de un Patrón de Interfaz Patrones de Interacción Móvil
150. Ejemplo de un Patrón de Interacción Patrones de Interacción Móvil Nombre Formatos de datos de fechas Martijn van Welie Problema El usuario desea introducir datos de fechas y no desea preocuparse por la sintaxis del dato Solución Permitir que el usuario elija la fecha de un calendario tal como se encuentra en el mundo real y que solo realice selección –el usuario no tipea. Contexto Todos los sistemas que requieran que el usuario introduzca fechas (importante en interfaces internacionales) Fuerzas - - Los datos de fechas tienen múltiples sintaxis - Principio Usabilidad - Guiar al usuario y prevenir errores - Convenciones culturales determinan la sintaxis esperada Ejemplo
151.
152.
153.
154. Patrones de Diseño Los patrones se derivan del diseño de software exitoso y que pueden ser reutilizados como bloques de construcción para nuevos diseños . Patrones Móviles Los patrones móviles cubren áreas del problema que los autores encontraron frecuentemente en los escenarios móviles Los patrones móviles relacionados pueden agruparse en patrones de clases, utilizando una Jerarquía de Patrones. Patrones de Interacción Móvil
156. Jerarquía de Patrones Los patrones móviles no solo son aplicables en los escenarios móviles Los patrones de diseño que aparecen frecuentemente en escenarios móviles son buenos candidatos para nuevos proyectos Patrones de Interacción Móvil
163. Proxy - Patrón Móvil de Interacción Patrones de Interacción Móvil ServiceUsage, MobileService CLASES PushObject, RequestObject PATRONES RELACIONADOS ProxyWeb ( http://www.intellisync.com ) permite a usuarios handhelp usar browser sin forzar las limitaciones. El proxy preprocesa las paginas , descarga las imágenes y pre calcula el layout apropiado. Como resultado la cantidad de datos transferidos al dispositivo es reducido drásticamente. PocketDreamTeam es la versión PalmOS. EJEMPLOS
164. Proxy - Estructura Patrones de Interacción Móvil Client …… . ... Real Subject ...
165. Editor de documentos (Ej.) DocumentEditor Graphic ImageProxy Image Draw() GetExtend() Store() Load() Draw() GetExtend() Store() Load() Draw() GetExtend() Store() Load() Image If (Image==0) { Image=LoadImage(Name); } Image->Draw(); If (Image==0) { return extend; }else { return Image->GetExtend(); } ImageImp extend Name extend Patrones de Interacción Móvil
166.
167.
168.
169.
Notas del editor
Este tercer enfoque es rearquitectar los sistemas tal que una capa intermedia se crea entre las aplicaciones y las bases de datos. Este enfoque usa tecnología off-the-shell llamadas middleware y enterprise application integration o EAI. Las aplicaciones se modifican para que “llamen” al middleware el cual a su vez llama a los servidores (otras aplicaciones o bases de datos). Este enfoque permite cambiar las aplicaciones sin modificar las bases de datos. Tambien reduce el tiempo de mantenimiento. Este enfoque no exige mucho cambio organizacional. Pero requiere de una amplia experticia técnica. Markus, 2000
En este tipo de arquitectura, el cliente sólo tiene capacidades de ‘presentación’, pues toda la lógica del negocio tiene lugar en el lado del servidor.
Browser del cliente (Browser HTML estándar con soporte para forms) El browser es utilizado por el usuario de la aplicación para solicitar páginas Web (HTML o del servidor) y muestra las páginas html devueltas por el servidor Web. Sus Funciones/Servicios son 1.- Actuar como interfaz de usuario generalizada : toda interacción usuario/sistema se realiza a través del browser. La organización y apariencia de las páginas web es lo que conforma la interfaz de usuario de una aplicación Web . En estas aplicaciones, el browser actúa como un contenedor de interfaces de usuario generalizado, pues cada interfaz de usuario específica está definida por el contenido de una página Web (texto y controles de entrada). 2.- Aceptar y devolver ‘cookies’ Servidor Web (Punto de acceso principal al sistema para los browsers cliente) Sus Funciones/Servicios son: 1.- Aceptar peticiones de páginas Web, y según el tipo de petición... Iniciar procesamiento en el lado del servidor Delegar el procesamiento en un intérprete de scripts o un módulo ejecutable 2.- Devolver páginas HTML al browser Conexión HTTP (Protocolo de comunicación entre browsers cliente y servidores Web) Tipo de Comunicación SIN CONEXIÓN, puesto que cada vez que cliente y servidor intercambian información, se establece una conexión nueva y separada. La conexión sólo existe durante el procesamiento de una petición de página. Una vez que la petición ha sido satisfecha, la conexión finaliza. Toda actividad sobre el servidor (debida al usuario) ocurre durante la petición de página. Esto representa una muy importante diferencia con las aplicaciones cliente/servidor tradicionales . Secure Sockets Layer (SSL) es una variación de HTML que permite el intercambio de información encriptada.
Esta arquitectura mínima carece de algunos componentes opcionales que son encontrados normalmente en aplicaciones Web.
La persistencia se explica en la transparencia siguiente. -- Otra opción añadida a la arquitectura de cliente web ligero es la integración con sistemas heredados y, para aplicaciones de comercio electrónicos, con sistemas de contabilidad de mercado. Integración con Sistemas Heredados y Sistemas de Contabilidad de Mercado Se accede a estos componentes a través de los objetos del negocio, si existe, y si no, vía el Servidor de Aplicaciones. Sistemas heredados: Sistema de contabilidad o Sistemas de programación de producción Sistema de contabilidad de mercado permite que una aplicación Web para Internet, acepte y procese pagos con tarjetas de crédito para empresas más grandes, puede ser una interfaz con un sistema existente que procese solicitudes de dichos pagos
Explicar con pág. 103 ¡¡ corregido del libro, pues estoy convencida de que en la figura hay un par de flechas que no están en su sitio!!
Si los procesos ejecutados en el servidor tardan mucho, entonces este patrón puede no ser adecuado, sería necesario quizá descargar algo al servidor... Por otro lado, el browser es el único mecanismo de entrega de interfaces de usuario. Por tanto, las capacidades de dichas interfaces están limitadas a lo que soporte el browser y la versión de html utilizada.
Uno de los componentes más utilizados en Internet relacionado con la interfaz de usuario es el control y plug-in Shockwave ActiveX. Permite animaciones interactivas y se usa sobre todo para condimentar sitios de Internet con gráficos atractivos, así como para mostrar simulaciones y monitorizar eventos deportivos.
* Puesto que la comunicación entre cliente y servidor se realiza vía HTTP, la mayor parte del tiempo NO EXISTE conexión abierta entre ellos. Esto significa que los scripts del cliente, controles ActiveX y applets Java sólo pueden interactuar con objetos del cliente. * El patrón Cliente Web Pesado utiliza ciertas capacidades del browser : 1) Controles ActiveX o Applets de Java para i)ejecutar lógica del negocio en el cliente o ii)tratar aspectos de interfaz de usuario . Un control ActiveX es código binario ejecutable compilado que puede ser descargado al cliente vía HTTP e invocado por el browser. 2) Scripts del cliente. Las páginas HTML pueden contener scripts escritos en JavaScript o VBScript. Esta capacidad permite al browser interpretar código que puede ser i)parte de la lógica del negocio del sistema o ii)tratar aspectos de interfaz de usuario . Estos scripts son elementos que potencialmente son significativos para la arquitectura del sistema.
Una cuestión importante del diseño de aplicaciones Web es comprender este paradigma de interacción cliente-servidor. Los objetos de negocio no siempre están accesibles cuando se manejan peticiones de IU individuales. Por ejemplo, una característica común de interfaz de usuario (y del negocio) en muchas aplicaciones cliente/servidor es el rellenado automático de los campos de “ciudad” y “estado” en una dirección postal de USA, cuando se introduce un código zip. Asumiendo que esos tres campos están localizados en la misma página en un browser, esta característica requeriría una solicitud adicional de una página del servidor inmediatamente después de la introducción del valor en el campo “código zip”. Para la amplia mayoría de aplicaciones Web esto supondría una pérdida de rendimiento inaceptable, pues las peticiones de páginas suelen ser satisfechas en un tiempo del orden de segundos y no de milisegundos.
Cuando se utilizan scripts del cliente, applets o controles, el equipo de pruebas debe realizar un conjunto completo de escenarios de prueba para cada configuración de cliente que deba ser soportada. Puesto que se está ejecutando lógica del negocio crítica en el cliente, es importante que se comporte de forma correcta y consistente en todos los browsers involucrados Una desventaja del uso de applets es que cada browser implementa su propia versión de Java (máquina virtual Java). Y además, van muy por detrás de Sun (creador de Java). Todo esto implica que un applet puede no ejecutarse correctamente o igual en browsers diferentes.
El Web es utilizado sobre todo como un mecanismo de entrega para un sistema cliente/servidor de objetos distribuidos diferente del tradicional. Son aplicaciones cliente/servidor de objetos distribuidos que incluyen un servidor Web y un browser de cliente como elementos significativos para su arquitectura. Puede verse como una aplicación Web con objetos distribuidos o un sistema de objetos distribuidos con elementos Web.
El Web es utilizado sobre todo como un mecanismo de entrega para un sistema cliente/servidor de objetos distribuidos diferente del tradicional Aplicaciones cliente/servidor de objetos distribuidos que sólo incluyen un servidor Web y un browser de cliente como elementos significativos para su arquitectura. La mayor fortaleza de esta arquitectura es la capacidad de distribuir objetos de negocio existentes en el contexto de una aplicación Web. Con la comunicación directa y persistente entre cliente y servidor, se evitan las limitaciones de las anteriores arquitecturas. El cliente puede realizar lógica del negocio importante hasta un grado mucho mayor. No suele utilizarse en aislado, sino en combinación con alguno de los otros. Lo más típico es usar uno o ambos de los patrones anteriores para aquellas partes del sistema que no requieren una IU sofisticada o donde las configuraciones del cliente no son lo bastante fuertes como para soportar una aplicación cliente grande.
La mayor diferencia con los otros patrones: el protocolo de comunicación entre cliente y servidor. Si antes era HTTP, ahora se utiliza protocolos DCOM o RMI/IIOP.
Lo principal es el uso de un browser que contiene la interfaz de usuario y algunos objetos del negocio que se comunican independientemente del browser, con objetos del servidor (vía IIOP, RMI o DCOM) Ventaja principal: El browser tiene capacidades nativas para descargar automáticamente los componentes necesarios desde el servidor . Un nuevo equipo sólo necesita de un browser Web compatible para comenzar a utilizar la aplicación. No se necesita la instalación de software manual en el cliente, porque el browser se encarga de ello por el usuario. Los componentes son distribuidos e instalados en el cliente según se necesitan. Tanto applets Java como controles ActiveX pueden ser enviados automáticamente y metidos en la caché del cliente. Cuando esos componentes son activados, como resultado de la carga de la página Web apropiada, pueden interconectarse en una comunicación asíncrona con objetos del servidor.
Ejemplos: aplicaciones que requieren soportar diferentes sistemas de software. Componentes: Microkernel, Internal Server, External Server, Client, Adapter. Conectores: Interfaces de programación del Microkernel (para Internal Server, External Server, Adapter), Interfaces de programación del Servidor Externo (para Client)
Ejemplos: CLOS y Java. Componentes: A un meta nivel (provee información sobre las propiedades del sistema) y a un nivel base (contiene la lógica de la aplicación) Conectores: Protocolos que comunican los dos niveles.
Ejemplos: Java Virtual Machine, Java Class Libraries (AWT, Swing), Microsoft Foundation Classes (MFC). Componentes: aplicación componente, Wrapper Fa çade, funciones API. Conectores: Mecanismos de comunicación de las clases.
Ejemplos: Java Virtual Machine, Java Class Libraries (AWT, Swing), Microsoft Foundation Classes (MFC). Componentes: aplicación componente, Wrapper Fa çade, funciones API. Conectores: Mecanismos y protocolos de comunicación entre los componentes.
Ejemplos: Component-Based Application Servers, implementaciones de CORBA (COM), Web browsers, reflective ORB. Componentes: Context, concrete framework dispatcher, application, interceptor, concrete interceptor . Conectores: Mecanismos y protocolos de comunicación entre los componentes.
Ejemplos: Implementaciones de CORBA, COM/COM+, CCM, Enterprise Java Beans. Componentes: Root interface, extension interface, component, component factory, client. Conectores: Mecanismos y protocolos de comunicación entre los componentes.
Ejemplos: Implementaciones de CORBA, ODBC, SQL-Net. Componentes: Repositorio de datos centrales y agentes. Conectores: Mecanismos y protocolos de comunicación entre los componentes.