3.creacion de componentes visuales

1

Desarrollo de interfaces: 3.Creación de Componentes Visuales

Jose Alberto Benítez [email protected]

@indiproweb

Jose Alberto Benítez Andrades– [email protected] - @indiproweb

mailto:[email protected]

http://www.indipro.es/

2

Creación de Componentes Visuales

Desarrollo de software basado en componentes. Reutilización del software. Beneficios

Concepto de componente: Características

Propiedades y atributos: Propiedades simples e indexadas Ámbito de las propiedades Atributos para los miembros de un componente o control Atributos

que afectan en tiempo de diseño y en tiempo de ejecución.

Jose Alberto Benítez Andrades– [email protected] - @jabenitez88

3

Creación de Componentes Visuales

Eventos Asociación de acciones a eventos Generalizar el componente mediante creación de eventos. Comunicación del componente con la aplicación que lo usa, parámetros por valor y

por referencia.

Persistencia del componente Extender la apariencia y el comportamiento de los

controles en modo de diseño. Integrar controles existentes en nuestros componentes. Herramientas para el desarrollo. Empaquetado de componentes


4

POC - Introducción

A pesar de la aparente evolución que ha sufrido la programación a lo largo de los últimos 40 años, el desarrollo de una aplicación continúa siendo una actividad costosa en tiempo y dinero, y los errores en el producto final son frecuentes

El problema es que el nivel de reutilización sigue siendo muy escaso, a pesar de la multitud de librerías, toolkits y frameworks existentes


5

POC - Introducción

El uso de librerías gratuitas/comerciales presenta varios inconvenientes: Su instalación puede ser compleja Es frecuente que tengan dependencias con otras librerías Suelen tener una aplicación demasiado general: EEDD, GUIs,

comunicación por red, etc. pero rara vez solucionan aspectos de un problema concreto

Aunque es evidente que ahorran trabajo, sigue siendo necesario una gran cantidad de programación, aunque a otro nivel

Pueden requerir un tiempo de aprendizaje largo, incompatible con la realización de un proyecto con un plazo de ejecución limitado

Estos inconvenientes impiden la generalización de la reutilización de código existente en el desarrollo de software

Por tanto en general cada nuevo proyecto sigue requiriendo la escritura de una gran cantidad de código original


6

POC - Introducción

En cambio, en otras ingenierías como la electrónica el grado de reutilización es altísimo

En este ámbito, la construcción de un dispositivo electrónico se reduce a la integración de la manera adecuada de distintos componentes comerciales.

Existe fabricantes especializados en la fabricación de componentes y otros en la de dispositivos finales

El producto final obtenido es de calidad y se realiza en un tiempo relativamente corto


7

POC - Introducción

La solución a la crisis del software pasa por cambiar el modelo de desarrollo a un desarrollo orientado a componentes

Se basa en la construcción de una aplicación a partir de componentes software comerciales o gratuitos ya existentes, limitando al mínimo necesario el desarrollo de código nuevo

Para que este cambio se produzca es necesaria la creación de un mercado amplio de componentes software de calidad y con un ámbito de aplicación general


8

POC - Introducción

También será necesaria la adopción de una arquitectura estandarizada que garantice la interoperatividad de los componentes en distintas plataformas, lenguajes de programación y entornos de desarrollo

La implantación de este modelo tiene múltiples beneficios● El desarrollo será mucho más sencillo y en un tiempo y con un coste menores● La posibilidad de errores es mínima ya que los componentes son sometidos a un riguroso control de calidad antes de ser comercializados● Las empresas de desarrollo especializadas pueden obtener ingresos adicionales vendiendo componentes a otras empresas


9

POC - Introducción

La programación basada en componentes es aquella que está basada en la implementación de sistemas utilizando componentes previamente programados y probados.

Los componentes están bien definidos en todas las demás disciplinas de la ingeniería, sin embargo, debido a la propia naturaleza del software, en ésta disciplina aun no está todo completamente definido.


10

POC - Introducción

La composición habilita cosas prefabricadas para ser reusadas posteriormente en nuevas composiciones cualesquiera.

Para convertir un elemento en reusable, no es suficiente iniciar con un diseño monolítico de una solución completa y entonces particionarla en fragmentos. Las descripciones de los componentes deben estar generalizadas cuidadosamente para permitir la reusabilidad en un número suficiente de diferentes contextos.


11

POC - Introducción

Los componentes de software son unidades ejecutables de adquisición, implementación y producción independiente que pueden formar parte de un sistema funcional.

El requerimiento de la independencia y la forma ejecutable elimina

muchas abstracciones del software; tales como declaraciones de tipo, macros de C ó plantillas de C++. Otras abstracciones, como procedimientos, clases, módulos, o aún aplicaciones enteras, pueden formar componentes, mientras estén en una forma ejecutable que sea integrable. (Motivo)


12

POC - Hechos a la medida VS Software Estándar

El desarrollo tradicional de software se divide en dos partes:

Un proyecto desarrollado en su totalidad línea por línea con solo la ayuda de herramientas de programación y librerías.

Se compra software estándar y se parametriza para proporcionar una solución que está muy cerca de ser lo que requiere el cliente.


13

POC - Ventajas y desventajas de:


(Si funciona) Puede ser adaptado al modelo del negocio del cliente.

La producción este tipo de software es una empresa muy costosa (mantenimiento).

La mayoría de los proyectos grandes fallan parcialmente o totalmente, conduciendo a un riesgo sustancial (interoperabilidad con otros sistemas locales).

En un mundo de rápidos y continuos cambios en los requerimientos de los negocios, este tipo de software es usualmente muy lento para ser productivo antes de convertirse en obsoleto.

14

POC - Ventajas y desventajas de (2) :


Disminuye el riesgo. El vendedor de sw estándar busca disminuir los problemas del mantenimiento, de la evolución del producto, y de la interoperabilidad.

Parametrización y configuración detallada entre las versiones (inevitable en un mundo de cte. cambio).

Implica una reorganización del proceso del negocio en cuestión. Debido a que no está bajo control local, no es suficientemente apto para

adaptarse rápidamente a cambios, en los requerimientos, que pudieran surgir.

15

POC - El papel de los componentes

El concepto de componente de software representa una posible solución. Aunque cada componente comprado es un producto estandarizado, con todas las ventajas adjuntas, el proceso de ensamblar componentes ofrece la oportunidad de ser una actividad muy atractiva para el cliente.

En la solución basada en componentes, la evolución reemplaza la revolución, y la actualización individual de componentes que se requiera permite operaciones más suaves. Obviamente, se requiere un camino diferente para administrar los servicios, pero los beneficios potenciales son inmensos.


16

POC - Los componentes son inevitables

Gran aceptación en su uso si ofrecen suficiente variedad y calidad.

Una vez satisfaciendo las necesidades de los clientes, el uso de componentes se vuelve inevitable.

Componentes no disponibles provoca la reinvención de nuevas soluciones. Justifidas solo si la solución creada es superior a la alternativa que se puede comprar.

Un producto que utiliza los beneficios de los componentes hace uso de una combinación de productividad e innovación de todos los vendedores de componentes.


17

POC - Naturaleza del SW e implementación de entidades

Inicialmente los componentes de sw fueron considerados similares a los componentes de hw, como los CI (“CI de software”). También en Mecánica e ingeniería civil.

Sin embargo, el software es diferente a los productos de todas las demás disciplinas de ingeniería.

Es importante distinguir entre el software y sus instancias para así diferenciar entre modelos y productos (plano-edif.)

Los planos pueden ser parametrizados, aplicados recursivamente, escalados, e inicializados cualquier número de veces. Actividades no aplicables a instancias.

El SW es un metaproducto genérico que puede ser usado para crear familias enteras de instancias.


18

POC - Componentes: Unidades de Implementación

La unidad de implementación es algo más estático que un objeto; como una clase, o un conjunto de clases, compilado y enlazado en algún paquete. Y debido a que los objetos casi nunca se compran o venden, éstos no constituyen unidades de implementación.

La definición de objetos es puramente técnica – la encapsulación del estado y el comportamiento, el polimorfismo, y la herencia. Esta definición no incluye nociones de independencia o composición posterior.

Un componente debe tener un número considerable de usos y de clientes, para que sea viable. El “uso repetido” está detrás del concepto de reusabilidad.


19

POC - ¿Dónde encontramos este tipo de programación?

Visual Basic de Microsoft. Java. Enterprise JavaBeans (EJB). COM+. Todos los sistemas operativos modernos. Recientemente, las arquitecturas “plugin”. Arquitecturas en la web basadas en ASP’s Arquitecturas en la web basadas en JSP’s Integración de servidores alrededor de J2EE y COM+ / .NET


20

POC - ¿Dónde encontramos este tipo de programación?

Múltiples componentes de diferentes fuentes pueden coexistir en la mima instalación.

Los componentes existen en un nivel de abstracción en el que significan algo directamente para el cliente (Visual Basic).

La mayoría de los objetos no tienen significado para los clientes que no son programadores.

Configurar e integrar un objeto individual dentro de algún sistema dado no es posible normalmente, así que los objetos no pueden ser vendidos independientemente como los componentes.


21

POC – El mercado y la tecnología

Los componentes son activos reutilizables. Resolver un problema general en lugar de uno específico implica más

trabajo. Los componentes son viables sólo si la inversión en su desarrollo

regresa como un resultado de su venta.

“Tecnología imperfecta en un mercado de trabajo es sostenibleTecnología perfecta sin ningún mercado será vana”


22

POC – Crear un mercado

Un nuevo producto puede crear un mercado solo si su llegada ya se estaba esperando.

Un camino elegante es el que evita crear mercados y se expande cuidadosamente en mercados ya establecidos. (estrategia de Microsoft con su V. Basic en Internet).

La producción de componentes debe ser menos costosa que la producción de soluciones completas. Además, el empaquetarlos o ligarlos con componentes relacionados ayuda a disminuir los costos de distribución; pues algunos componentes no son capaces de sostener, solos, los precios que los podrían hacer viables.


23

POC – Propiedades fundamentales de la Tecnología de Componentes

El establecimiento de mercados de componentes descansa en la factibilidad tecnológica.

En un mercado abierto de desarrolladores de componentes independientes, el conjunto de posibles combinaciones (en el uso de componentes) no es conocido por ninguna de las partes involucradas.

Los componentes necesitan estar construidos de tal manera que permitan una comprobación modular.

La seguridad (si hay fallas no se debe colapsar el Sist.) La funcionalidad. El rendimiento.


24

POC – Desarrollo de un mercado

ComponentSource ocupa un de los lugares más amplios dentro del mercado de componentes de software y desarrollo de herramientas. Preferencia por COM (ActiveX).

http://www.componentsource.com/index-es.html


http://www.componentsource.com/index-es.html

25

POC – Distribución de los componentes ofrecidos ComponentSource


Mercado compartido en ComponentSource.

• Flashline es otra compañía importante en el mercado de componentes de SW. Comparada con ComponentSource, se enfoca en el desarrollo de componentes para el servidor y tiene preferencia por las tecnologías basadas en Java.

26

POC – ESTÁNDARES

Los estándares son útiles para establecer acuerdos entre los modelos comunes, habilitando en un principio la interoperabilidad.

Los estándares también pueden ser usados para crear acuerdos en especificaciones concretas de interfaces, habilitando una composición efectiva.


27

POC – Importancia de los cuasi estándares

Para que un componente encuentre un razonable número de clientes, necesita tener requerimientos que puedan ser ampliamente soportados.

También necesita proporcionar servicios que puedan ser ampliamente solicitados.

Un componente necesita sostener una porción significativa de un mercado específico en su dominio.


28

POC – Importancia de los cuasi estándares

Si un componente cubre las necesidades de un número pequeño de clientes, el vendedor conocerá exactamente las necesidades individuales de los clientes (el caso extremo es el desarrollo de componentes para solo un propósito y sólo para un cliente).

Como el número de usos potenciales y de clientes potenciales crece, es improbable que que cualquier componente pueda cubrir todas las necesidades mientras es implementado.

El punto medio inevitable en el que clientes y vendedores necesitan posicionarse es el que está basado en los estándares.


29

POC - ¿Dónde está la tecnología de componentes hoy en día?

Es claro que los componentes de un dominio general se convertirán en los más provechosos de todos y esos mercados substanciales serán creados.

Sin embargo, los estándares de dominio específicos plantean hoy la mayoría de las preguntas. ¿Deben los estándares venir antes de los productos y de los mercados, o viceversa?

Ni los productos ni los bosquejos de estándares han alcanzado un nivel de madurez o de impacto que permita a cualquier predicción hoy en día.


30

POC - Fundamentación

¿Qué es un componente y qué no lo es?Los términos “componente” y “objeto” son a menudo usados de

forma intercambiable.

La programación orientada a componentes se apoya de conceptos que fundamentan este paradigma, así como modelos de diseño, metodologías, estándares e incluso problemas.


31

POC - COMPONENTE

“Unidad de composición de aplicaciones de software, que posee un conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio.”

Las propiedades características de un componente son:

Es una unidad software compilada reutilizable, con una interfaz bien definidaSe distribuye en un único paquete instalable que contiene en sí todo lo

necesario para su funcionamiento, con ninguna o muy pocas dependencias con otros componentes o librerías

Puede estar implementado en cualquier lenguaje de programación y ser utilizado también para el desarrollo en cualquier lenguaje de programación

Normalmente es un producto comercial de calidad, realizado por un fabricante especializado. Por supuesto pueden existir componentes gratuitos


32

POC - COMPONENTE

Las terceras partes no pueden acceder a los detalles de construcción del componente.

Debe ser suficientemente autocontenido.

Especificaciones claras de lo que requiere y de lo que proporciona.

Interacciona con su entorno a través de interfaces bien definidas.

No tener estados observables desde el exterior excepto atributos no funcionales como el número de serie.


33

POC - COMPONENTE

Son unidades de peso pesado, existe solo una copia.

Por tanto, en un proceso se puede decir si hay o no un componente, pero no varias instancias del mismo.

Propósito de rehúso bien definido.

No puede ser parcialmente implementada


34

POC - COMPONENTE

Un componente puede ser implementado mediante cualquier lenguaje de programación, aunque los lenguajes orientados a objetos son especialmente adecuados para este fin

El entorno de desarrollo es ahora más que un simple editor de código. Un entorno de desarrollo orientado a componentes debe facilitar la instalación de componentes y su configuración e integración en una aplicación. El código fuente adicional necesario es mínimo


35

POC – OBJETO

“Un objeto es una unidad de instanciación con una identidad única, unestado y un conjunto de operaciones. El estado esta representado por el conjunto de valores que toman las propiedades en un instante de tiempo, el cual varía dinámicamente como resultado de la ejecución de sus operaciones.”

En contraste con las propiedades características de un componente, las propiedades características de un objeto son las siguientes:

Es una unidad de instanciación, tiene una única identidad.Puede tener estados y estos pueden ser observables externamente.Encapsula su estado y comportamiento.


36

POC – OBJETO

No puede ser parcialmente instanciada.

Como los objetos son instanciados necesitan tener un plan de construcción que describa el espacio del estado, el estado inicial y el comportamiento del nuevo objeto.

La clase es la plantilla genérica que define el espacio de estados posibles del objeto y a partir de la cual se pueden instanciar los objetos.


37

POC – COMPONENTES Y OBJETOS

No hay necesidad para que un componente contenga clases únicamente.

Un componente puede contener:

Procedimientos tradicionales, y siempre tener variables globales. Puede ser realizado en su totalidad utilizando programación

funcional. Cualquier otro enfoque.


38

POC – Dependencias del contexto

Interfaces requeridas

Entorno de componentes para el cuál esta preparado (COM, CORBA, .NET, J2EE).

Plataforma (Hardware/Software)


39

POC – Interfaces

Determinan las operaciones que el componente implementa como las que precisa utilizar de otros componentes durante la ejecución.

Usualmente son los atributos y métodos públicos que el componente implementa más los eventos que emite.

La especificación de las interfaces es un contrato. El respeto de este contrato por parte del cliente y componente

asegura el éxito de la interacción


40

POC – Contratos de Especificación

Un contrato de especificación establece las condiciones de uso e implementación que ligan a los clientes y proveedores del componente.

Los contratos cubren aspectos tanto funcionales (semántica de las operaciones de la interfaz) como no funcionales (calidad de servicio, prestaciones, fiabilidad o seguridad).


41

POC – Estados y Contratos del Componente

En su estado final el componente representa una unidad de ejecución o utilización que opera en un modelo de componentes (CORBA, .NET, J2EE, etc.),

Especificación del Componente. Esta fase especifica el componente de manera independiente a la plataforma en la que va a ser construido. La especificación del componente se alcanza a través de la especificación de las interfaces que lo conforman.

Implementación del Componente. En esta fase se realiza o traduce la especificación ya definida a un entorno de implementación concreto, utilizando un lenguaje de programación determinando y respetando los reglas que establece un modelo de componentes.

Instalación del componente. Se ejecutan las acciones necesarias para dar disponibilidad del componente en la plataforma específica, para ser utilizado por las diferentes aplicaciones.


42

POC – Estados y Contratos del Componente

Objeto Componente. Instancia de un componente ya instalado en el momento cuando este va a ser invocado para su utilización.

Se distinguen dos tipos de contrato:

El contrato de uso que establece un acuerdo entre la interface del objeto componente y sus clientes

El contrato de realización que establece un acuerdo entre la especificación del componente y sus implementaciones.


43

POC – Programación Orientada a Componentes

La programación basada en componentes(PBC) es aquella que se basa en la implementación de sistemas utilizando componentes previamente programados y probados. La construcción de esos componentes se realiza mediante la programación orientada a componentes.

Variante natural de la programación orientada a objetos para los sistemas abiertos.

Objetivo: Construir un mercado global de componentes (MGC) cuyos usuarios son los propios desarrolladores de aplicaciones que necesitan reutilizar componentes ya hechos y probados para construir sus aplicaciones de forma más rápida y robusta o que quieren añadir funcionalidad dependiente de terceros.


44

POC – Programación Orientada a Componentes

Entidades básicas: Componentes - cajas negras que encapsulan cierta funcionalidad y que son diseñadas para el Mercado Global de Componentes sin saber quién las utilizará, ni cómo, ni cuándo.


45

POC – POC frente a la POO

Una diferencia entre las dos metodologías es la manera en la cuál visualizan la aplicación final.

La POO se enfoca en las relaciones entre las clases que están combinadas dentro de un programa en formato binario ejecutable.

La POC se enfoca en los módulos de código intercambiables que trabajan independientemente y no requieren que nosotros estemos familiarizados con su forma de trabajar interna.


46

POC – POC frente a la POO

Si alguna clase sufre cambios: Re-enlazamiento masivo de la aplicación completa Realizar nuevamente las pruebas Re-implementación de posiblemente todas las demás clases.

Si es necesario modificar un componente:Los cambios son contenidos solo en el componente. No existiendo la necesidad de re-compilación o re-

implementación. Pueden ser actualizados aunque la aplicación este corriendo,

mientras el componente no se encuentre en uso.


47

POC – Beneficios que proporciona la POC

Una aplicación orientada a componentes es fácil de extender. Cuando se tienen nuevos requerimientos a implementar, se pueden proveer nuevos componentes, sin tocar los componentes existentes, no afectándolos asípor los nuevos requerimientos.

Esos factores permiten a la programación orientada a componentes reducir el coste a lo largo de la etapa de mantenimiento, esto es un factor esencial en la mayoría de los negocios, en los cuales sé esta extendiendo el uso de la tecnología de componentes.


48

POC – Otros conceptos básicos de POC

Componentes COTS Composición tardía Entornos Eventos Polimorfismo Reflexión


49

POC – Tendencias de la POC

Lenguajes de programación Java, Component Pascal, Oberon, Módula 3 y ADA 95

Modelos de desarrollo Aspectos de calidad en componentes


50

POC – Problemas de la POC

Clarividencia Percepción del entorno Falta de soporte formal Interoperabilidad


51

POC – Diseño Basado en Componentes

En el DSBC, pueden identificarse varias tareas específicas para la construcción de aplicaciones utilizando componentes COTS:

(1) La búsqueda (trading) de componentes que satisfagan los requisitos impuestos tanto por el cliente como por la arquitectura de la aplicación

(2) La evaluación de los componentes candidatos para seleccionar los más idóneos;

(3) La adaptación y/o extensión de los componentes seleccionados para que se ajusten a los requisitos anteriores.

(4) La integración, configuración e interconexión de dichos componentes para construir la aplicación final.


52

POC – Diseño Basado en Componentes

Un factor imprescindible en todas esas tareas es la documentación de los componentes.

Lenguajes de descripción de interfaces (IDL’s)

Documentar requerimientos no funcionales


53

POC – Ingeniería de Software Basada en Componentes

En la Ingeniería de Software Basada en componentes (Component Based Software Engineering CBSE) el desarrollo de una solución software se percibe como un trabajo de adaptación y composición a partir de componentes, los cuales pueden tener diversos orígenes: ya desarrollados para uso genérico, comprados, o desarrollados a la medida.

Objetivos

Desarrollar sistemas a partir de componentes ya construidos.

Desarrollar componentes como entidades reusables.

Mantener y evolucionar el sistema a partir de la adaptación y reemplazo de sus componentes.


54

PROGRAMACIÓN, MODELOS Y PLATAFORMAS DE COMPONENTES( RM-ODP, Corba de OMG, JAVA, JAVA/RMI , JavaBeans y DCOM )


55

POC – Plataformas de Componentes

Basadas en un modelo concreto Ofrecen una implementación de los conceptos y

mecanismos del modelo Proporcionan entornos de desarrollo y ejecución para los

componentes Suelen ofrecer pasarelas a otros modelos y plataformas Ejemplos: ActiveX/OLE, Enterprise Beans, Orbix


56

POC – Componentes e interfaces

Interfaces: atributos, métodos y eventos

Lenguajes de definición de Interafaces (IDL) Interacción entre componentes

RPCs para los métodosPublish-and-subscribe para los eventosMensajes asíncronos


57

POC – Entornos de Desarrollo Integrados (IDE)

paletas lienzo o contenedor editores para configurar y especializar componentes browsers repositorio de componentes acceso a intérpretes, compiladores y depuradores herramientas de control y gestión de proyectos


58

RM-ODP RM-ODP: Modelo de referencia para el diseño de sistemas

abiertos y distribuidos Objetivo: hacer transparente al usuario la heterogeneidad

del:hardwaresistemas operativosredeslenguajes de programaciónbases de datostipos de gestión


59

RM-ODP RM-ODP se divide en:

Descripción general y recomendaciones de usoModelo descriptivoModelo prescriptivoSemántica arquitectónica

Conceptos fundamentales:TransparenciaPerspectivas: empresa, información, computacional,

ingeniería, tecnológicoFunciones y servicios comunesCorredor de servicios


60

RM-ODP Todas salvo la vista tecnológica son independientes de la

implementación


61

RM-ODP: VISTAS Punto de vista de la empresa

Modelos de objetos de negocio y políticas de empresa (permisos, prohibiciones y obligaciones)

Debe ser comprensible para los clientes y usuariosFacilita la validación de la arquitectura software respecto a las

necesidades de la empresa. Punto de vista de la información

Esquemas de información (objetos)– Esquemas estáticos, dinámicos e invariantes

Define el universo del discurso para el sistema de Información.Representación lógica de los datos y procesos del sistema de

informaciónModelos orientado a objetos


62

RM-ODP: VISTAS Punto de vista computacional

Encapsulamientos de objetos a alto nivel (interfaces y comportamiento)

Descompone el sistema en componentes software que puedan ser distribuidos.

Adopta la perpesctiva del diseñador de interfaces de componentes de programa de aplicación.

Define las fronteras entre los elementos software del sistema de información.

Estas fronteras son muy importantes en la evolución para adaptar el software a nuevos requerimientos y a cambios tecnológicos.


63

RM-ODP: VISTAS Punto de vista de ingeniería

Expresa la naturaleza distribuida del sistemaDeclara las trasparencias que soporta la infraestructuraEspecifica la asignación de nodos de procesamientoUsa canales (el modelo de referencia de infraestructura

distribuida) para modelizar todo tipo de conexiones middleware Punto de vista de la tecnología

Define correspondencias de los objetos de ingeniería, y otros de la arquitectura, con los estándares y tecnologías.

Punto de vista parecido al de un ingeniero de redes familiarizado con los protocolos estándar y productos comerciales disponibles que configura el sistema de información.


64

RM-ODP: TRANSPARENCIAS RM-ODP define ocho propiedades de trasparencia en distribución. Estas cualidades debe proporcionarlas la infraestructura distribuida.


Propiedad Garantía Arquitectónica

Acceso Oculta diferencias en protocolos, representación de datos y mecanismo de invocación

Fallo Oculta fallos y recuperaciones de otros objetos

Ubicación Oculta el uso de información de localización y ligadura a objetos

Migración Oculta las repercusiones del cambio de ubicación de un objeto sobre éste mismo

Reubicación Oculta cambios de la ubicación de una interface o un servicio de losclientes

Réplica Oculta la existencia de réplicas de objetos que soporten estados oservivios

Persistencia Oculta la activación/desactivación de objetos (incluso del mismo objeto)

Transacción Oculta la coordinación de actividades para lograr la consistencia

65

RM-ODP: definiciones estándar deobjetos de infraestructura distribuida

Estas definiciones permiten descripciones abstractas de las restricciones desde el punto de vista de ingeniería

Los objetos de ingeniería estándar pueden recoger las características de cualquier tipo de infraestructura distribuida:rpcInterfaces asíncronas para señales...


66



67


En RM_ODP pueden indicarse las conformidades necesarias Categorías de conformidad

Programación: comportamiento tras interfaces softwarePerceptual: interfaces de usuario externas al sistemaInterworking: entre implementacionesIntercambio: de medios de almacenamiento externo conformidad: cumplimiento de una restricción de la

especificación, por un producto o por una implementación


68


Aplicaciones y perfiles El estándar RM-ODP es muy genérico, aplicable a cualquier dominio,

pero para lograr esto, deben elaborarse perfiles específicos, planes de implementación del estándar en contextos específicos.

El estándar se ha aplicado en el mundo de las finanzas, en DoD americano , etc

El DoD ha definido y está usando el perfil C4ISR-AF Command, Control, Communications, Computers, Intelligence,

Surveillance, and Reconnaissance Architecture Framework


69

RM-ODP Notaciones usadas en las vistas

UMLODP IDL, similar al CORBA IDL, un estandar de especificación de

encapsulamientos de objetos, independiente de la plataforma de middleware, y del LP


70

CORBA


71

CORBA:Common Object Request Broker Architecture OMG: Object Management Group (1989)

Definición de estándares para permitir interoperabilidad y portabilidad

OMA: Object Management Architecture ORB: Object Request Broker (bus de objetos):

Bus de datos para la comunicación entre objetosTransparencia de la heterogeneidad, dispersión y activación de

objetos en sistemas abiertos y distribuidos


72

CORBA 1.1 Primera versión de CORBA (1991) Descripción concreta de las interfaces y los servicios que

deben proporcionar los implementadores de ORBs Elementos básicos de CORBA 1.1:

Núcleo del ORBLenguaje de Descripción de Interfaces (IDL)Repositorios de interfacesAdaptadores de objetos (OA)


73

CORBA 1.1 Objeto como pieza fundamental Cada objeto dispone de una referencia, y se comunica con

otros objetos mediante el ORB Comunicación: estática y dinámica El ORB se encarga de:

localizar los objetos sirvientes, activarlos (si no lo están), invocar el método solicitadodevolver el resultado al cliente

El Adaptador de Objetos (OA) se encarga de ocultar la implementación del objeto sirviente


74

CORBA 1.1 Objeto como pieza fundamental Cada objeto dispone de una referencia, y se comunica con

otros objetos mediante el ORB Comunicación: estática y dinámica El ORB se encarga de:

localizar los objetos sirvientes, activarlos (si no lo están), invocar el método solicitadodevolver el resultado al cliente

El Adaptador de Objetos (OA) se encarga de ocultar la implementación del objeto sirviente


75

IDL de CORBA Lenguaje textual y orientado a objetos (similar a C++) para

definir las interfaces de los objetos CORBA. Independiente del lenguaje en que se implementan los

objetos. Soporta herencia y polimorfismo. Los compiladores de IDLs se encargan de generar un

conjunto de módulos descritos en el lenguaje base. Existen compiladores para los principales lenguajes:

C, C++, Smalltalk, Java, Ada, Cobol. Las interfaces de los objetos definidos en un ORB se

registran en repositorios (a modo de páginas amarillas).


76

Estructura básica de un ORB


Adaptador de Objetos

Object Request Broker

DII IDL Stub IDLSkelDSI

Interfaz ORB

ClienteImplementación

Servidor

77

CORBA 2.0 CORBA 2.0 (1996)

proporciona servicios básicos para componentes CORBA que estandarizan y complementan los COSS (Common Object Service Specification):

trading, naming, events, etc.ofrece mecanismos de interoperabilidad entre distintas

implementaciones de ORBs Extensión de la arquitectura OMA:

Servicios Comunes (CORBAservices)Facilidades Comunes (CORBAfacilities)


78

CORBA 2.0 CORBA 2.0 proporciona 15 servicios comunes:

Acceso a las referencias de los objetos (naming)correduría de servicios (trading)localización (query)notificación (notification) y difusión de eventos

(events)transacciones (OTS)seguridad y confidencialidad (security)persistencia, concurrencia, reflexión, tiempo real, ...


79

FACILIDADES CORBA Conjunto de servicios de nivel superior a los

CORBAservices. Facilitan el desarrollo de aplicaciones CORBAfacilities horizontales (de carácter general):

impresión (print spooling)gestión del sistema (system management)correo electrónico (e-mail), ...

CORBAfacilities verticales (para dominios específicos):objetos de negocio, comercio electrónico,seguros y finanzas, ...


80

Arquitectura OMA


Object Request Broker

Servicios comunes(CORBAservices)

FacilidadesVerticales

FacilidadesHorizontales

Objetos yAplicaciones

81

GIOP y IIOP GIOP (General Inter-ORB Protocol)

Define todos los aspectos de interoperabilidad entre distintos ORBs, independientemente del nivel de transporte

IIOP (Internet Inter-ORB Protocol)GIOP + TCP/IPProtocolo recomendado por OMGCualquier ORB que proporcione pasarelas IIOP cumple

el estándar CORBA


82

CORBA 3.0 CORBA 3.0 (1998) añade:

Portable Object Adapters (POAs)Extienden los adaptadores de objetos básicos para

soportar sirvientes multihebra, persistentes, y permiten gestionar los sirvientes de una aplicación.

Invocaciones asíncronas (además de RPCs)Paso de objetos por valor y no sólo por referencia


83

Implementaciones de CORBA Existen más de 25 implementaciones de CORBA Orbix (Iona) Object Broker (Digital) Visibroker (Visigenic -Netscape) Component Broker (IBM)


84

Ejemplo de CORBA (1/4)


$ idl translator.idl

// fichero translator.idl

interface Translator {

string translate(in string frase);

};

//fichero Translator.java

//Generated by the OrbixWeb IDL compiler

public interface Translator

extends org.omg.CORBA.Object {

public String translate (String frase);

}

85

Ejemplo de CORBA (2/4) El fichero _TranslatorImplBase.java contendrá el esqueleto

de la implementación, invocando toda la funcionalidad de proxies, stubs, BOAs, etc. Esta implementación básica se puede extender:

public class TranslatorImplementation extends _TranslatorImplBase { public String translate(String s) { ...código interno de la función... }}


86

Ejemplo de CORBA (3/4) El código para arrancar el servidor podría ser:

import IE.Iona.OrbixWeb._CORBA;import IE.Iona.OrbixWeb.CORBA.ORB;public class orbixtranslator { public static void main (String args[]) { Translator txImpl = null; org.omg.CORBA.ORB orb =org.omg.CORBA.ORB.init(); txImpl = new TranslatorImplementation(); _CORBA.Orbix.impl_is_ready("orbixtranslator"); System.out.println("Shutting down server..."); orb.disconnect(txImpl); System.out.println("Server exiting..."); }}


87

Ejemplo de CORBA (4/4) Para registrar el sirviente en el repositorio CORBA:$ putit orbixtranslator -java orbixtranslator.class

Código de un clienteimport org.omg.CORBA.ORB;import IE.Iona.OrbixWeb._CORBA;public class Cliente { public static void main(String args[]){ ORB.init(); String srvHost = new String (args[0]); Translator TX = TranslatorHelper.bind(":orbixtranslator", srvHost ); System.out.println(args[1]+"->"+TX.translate(args[1])); }}


88

JAVA/RMI, JAVABEANS


89

Java/RMI, JavaBeans y Enterprise Beans Gran auge de Internet Inicialmente: acceso pasivo a la información 1995: CGI (Common Gateway Interface) 1996: Uso de Java en Internet Java como lenguaje de programación orientado a objetos JavaBeans: Un modelo de componentes Diversas extensiones: Glasgow, Edinburgh, Enterprise

Beans


90

Java Java es un lenguaje “simple, distribuido, interpretado,

robusto, seguro, independiente de la arquitectura, portable, multihebra y dinámico”

“Parcialmente” interpretado (bytecodes) Java aporta las “applets” Proliferación de plataformas soportando JVM Inclusión en los navegadores web


91

Java La computación no sólo se realiza en el servidor, sino que

es posible que los clientes ejecuten código que toman del servidor (applets).

La seguridad se comprueba tanto durante la carga como la ejecución de las applets.

Paquetes de especial relevancia para aplicaciones distribuidas:Empaquetamiento secuencial de objetos (serialization)Acceso a base de datos (JDBC)Invocación remota de métodos (RMI)


92

Empaquetamiento secuencial Objetos empaquetables como secuencias de datos. Cada stream incluye la identidad del objeto, su estado y

referencias a otros objetos. No existen problemas con la representación de los datos

(como ocurre en otras plataformas distribuidas), debido a la existencia de JVM.


93

JAVA / RMI RMI (Remote Method Invocation) implementa un modelo

cliente-servidor donde el cliente puede invocar de forma remota los métodos del servidor.

Extensión del concepto de RPC: los argumentos de las funciones invocadas pueden ser objetos que son transferidos de una máquina a otra.

RMI es un mecanismo dependiente del lenguaje (es una extensión de Java), pero es independiente de la plataforma (al estar basado en la máquina virtual JVM)


94

Ejemplo de Java/RMI (1/3) Una interfaz para generar el string “Hello ...”:public interface InterfaceHello extends java.rmi.Remote { public String hello() throws java.rmi.RemoteException}


95

Ejemplo de Java/RMI (2/3) La implementación de la interfaz y el servidor:public class ServerHello extends UnicastRemoteObject

implements InterfaceHello { public ServerHello() throws java.rmi.RemoteException {super();} public String hello() throws java.rmi.RemoteException {return “Hello... I’m the server...”;} public static void main(String argv[]) {ServerHello s; Registry registry = null; ... //Código para asignar registro try {System.setSecurityManager(new RMISecurityManager()); s = new ServerHello();

registry.rebind(“ServerHello”,s); }}


96

Ejemplo de Java/RMI (3/3) El clientepublic class ClientHello { public static void main(String argv[]) {InterfaceHello s; Registry registry; try {... //Código para obtener registro s = (InterfaceHello(registry.lookup(“ServerHello”); System.out.println(s.hello()); } catch (Exception e) {System.out.println(“System error”); System.out.println(e.getMessage()); e.printStackTrace(); }}


97

Arquitectura de 3 Niveles (3-tier) Java no define una infraestructura de objetos distribuidos,

sino que proporciona herramientas para su construcción y comunicación


RMI JDBCServidores

Aplicaciones

Applets

Cliente:Interfaces de

usuario

B.D.Almacenamiento

persistentede datos

JavaBeans JavaBeans (Sun Microsystems 1997) es un estándar sobre

Java que define el modelo de componentes Sun. Beans: componentes del modelo

Componentes software reutilizables que pueden ser manipuladas de forma visual por herramientas de desarrollo de aplicaciones

Granularidad y funcionalidad de las beans muy distintas: botón, hoja de cálculo, etc.


JavaBeans Interfaz: atributos, métodos y eventos. Inspección: a través de las herramientas visuales. Particularización: para adecuar la bean a los requisitos del

usuario o aplicación. Se realiza mediante la configuración de ciertos parámetros.

Persistencia: el estado de cada bean debe almacenarse para ser restaurado con posterioridad


JavaBeans JavaBeans es la tecnología de componentes de Java Los componentes de JavaBeans se conocen simplemente como

beans En principio un bean es simplemente una clase de objetos,

aunque con ciertas características especiales:Es una clase pública que implementa la interfaz SerializableExpone una serie de propiedades que pueden ser leídas y

modificadas desde el entorno de desarrolloExpone una serie de eventos que pueden ser capturados y

asociados a una serie de acciones Aunque los beans han sido pensados para ser utilizados desde el

entorno de desarrollo, también pueden ser utilizados directamente


JavaBeans La apariencia y comportamiento de un bean son

determinados por sus propiedades Una propiedad simple queda identificada por un par de

operaciones con la siguiente forma:public <TipoProp> get<NombreProp>() { ... }public void set<NombreProp>(<TipoProp> p) { ... }

●De esta forma queda definida la propiedad <NombreProp> de tipo <TipoProp>

●Si una propiedad no incluye la operación set, entonces es una propiedad de solo lectura


Vamos a transformar la clase TPAviso en un bean. Vamos a incluir tres propiedades: Mensaje (mensaje a imprimir), Activa (estado activo o no de la tarea) y PeriodoSegs (periodo de ejecución del aviso en segundos)


import java.util.*;import java.awt.event.*;import java.io.Serializable;import javax.swing.JOptionPane;import javax.swing.Timer;public class TPAviso implements ActionListener, Serializable {

int periodoSegs;String mensaje;Timer t;

public TPAviso() {periodoSegs = 60;t = new Timer(1000 * periodoSegs, this);

}

public TPAviso(String aMensaje, int aPeriodoSegs) {periodoSegs = aPeriodoSegs;

mensaje = aMensaje;t = new Timer(1000 * periodoSegs, this);

}

public void actionPerformed(ActionEvent e) {JOptionPane.showMessageDialog(null, mensaje, "Aviso",

JOptionPane.INFORMATION_MESSAGE);setActiva(false);

}

Vamos a transformar la clase TPAviso en un bean. Vamos a incluir tres propiedades: Mensaje (mensaje a imprimir), Activa (estado activo o no de la tarea) y PeriodoSegs (periodo de ejecución del aviso en segundos)


public void setActiva(boolean valor) {if (valor == true)

t.start();else

t.stop();}public boolean getActiva() {

return t.isRunning();}public void setMensaje(String aMensaje) {

mensaje = aMensaje;}public String getMensaje() {

return mensaje;}public void setPeriodoSegs(int aPeriodoSegs) {

periodoSegs = aPeriodoSegs;t.setInitialDelay(1000 * periodoSegs);if (t.isRunning()) {

t.restart();}

}public int getPeriodoSegs() {

return periodoSegs;}

}

Propiedad Activa

Propiedad Mensaje

Propiedad Periodo

Naturalmente este bean es utilizable como cualquier otra clase de Java. En principio no tiene ninguna cualidad extraordinaria. Los valores de las propiedades pueden se modificados mediante las operaciones set correspondientes


public class TPAvisoPrueba {public static void main(String[] args) {

TPAviso tpa = new TPAviso();tpa.setPeriodoSegs(5);tpa.setMensaje( Han pasado 5 segundos );tpa.setActiva(true);

try {System.in.readln();

}catch(IOException e) {};

}}

La forma habitual de distribución de un bean es en un fichero jar. Este fichero debe contener además un fichero manifest con el siguiente contenido:

Name: <NombreBean>.classJava-Bean: True

Para empaquetar el bean definimos un fichero manifest.tmp con el siguiente contenido:

Name: TPAviso.classJava-Bean: True

A continuación generaríamos el fichero jar:

jar cfm TPAviso.jar manifest.tmp TPAviso.class


Ya podemos instalar el bean en el netBeans (o cualquier otro entorno de desarrollo Java):


Y lo tendremos disponible en la paleta de componentes:


Podemos seleccionarlo y utilizarlo en la aplicación. Sus propiedades son editables de manera interactiva


netBeans se encarga de generar automáticamente el código de creación del componente y asignación de las propiedades:


Aspectos avanzados de las propiedades No hay que confundir “propiedad” con “atributo”

Ambos describen el estado interno y comportamiento, pero en dos contextos diferentes

Normalmente los atributos nunca son públicos. En cambio las propiedades siempre son características públicas de los componentes

Los atributos son accesibles únicamente a nivel de programación. Las propiedades son accesibles tanto a nivel de programación como interactivamente desde el entorno de desarrollo

Cuando se implementa un componente mediante una clase de objetos, cada propiedad suele estar asociada internamente a un atributo, aunque esto no ocurre siempre


Aspectos avanzados de las propiedades Una vez instalado el bean, el entorno de desarrollo es

capaz de identificar sus propiedades simplemente detectando parejas de operaciones get/set, mediante la capacidad de Java denominada introspeccion

El entorno de desarrollo es capaz de editar �automaticamente cualquier propiedad de los tipos basicos y las clases Color y Font. Sin embargo, logicamente no tiene capacidad para editar una propiedad de un tipo arbitrario (p. e., de la clase Cliente, Producto, etc.)

JavaBeans permite definir editores a medida para editar �estas propiedades


Aspectos avanzados de las propiedades Para ello seguiremos los siguientes pasos:

Construir una clase para la edición de la propiedad que implemente la interfaz PropertyEditor

El nombre de esta clase debe coincidir con el de la propiedad, terminando en “Editor” (por ejemplo, ClienteEditor)

Empaquetar el editor en el fichero jar del bean. El entorno de desarrollo utilizará el editor cuando necesite mostrar/editar la propiedad.

Ver “Bean Customization” del tutorial Java para más información


Aspectos avanzados de las propiedades Es posible definir también propiedades indexadas. Estas

propiedades representan colecciones de elementos y se identifican mediante los siguientes patrones de operaciones:

public <TipoProp>[] get<NombreProp>()public void set<NombreProp> (<TipoProp>[] p)public <TipoProp> get<NombreProp>(int index)public void set<NombreProp> (int index, <TipoProp> p)

La edición de este tipo de propiedades requiere la �implementación de un editor a medida, como hemos estudiado anteriormente


Generación de eventos Un bean puede generar una serie de eventos, que pueden ser capturados

y procesados externamente. Los pasos a seguir para incluir el soporte de un evento en un bean son los

siguientes:Definir una interfaz que represente el listener asociado al evento. Esta

interfaz debe incluir una operación para el procesamiento del eventoDefinir dos operaciones, para añadir y eliminar listeners. Estos

listeners deben ser almacenados internamente en una estructura de datos como ArrayList o LinkedList:

public void add<NombreListener>(<NombreListener> l)public void remove<NombreListener>(<NombreListener> l)

Finalmente, recorrer la estructura de datos interna llamando a la operación de procesamiento del evento de todos los listeners registrados


Vamos a incluir soporte de eventos en el bean TPAviso. Cada vez que se lance el aviso se generará un evento EventoAviso que puede ser capturado por aquellas clases interesadas


public class TPAviso implements ActionListener, Serializable {int periodoSegs;String mensaje;Timer t;LinkedList listeners;public TPAviso() {

periodoSegs = 60;t = new Timer(1000 * periodoSegs, this);listeners = new LinkedList();

}public TPAviso(String aMensaje, int aPeriodoSegs) {

periodoSegs = aPeriodoSegs;mensaje = aMensaje;t = new Timer(1000 * periodoSegs, this);listeners = new LinkedList();

}public void addEventoAvisoListener(EventoAvisoListener l) {

listeners.add(l);}public void removeEventoAvisoListener(EventoAvisoListener l) {

listeners.remove(l);}


private void fireEventoAviso(EventoAviso ea){

EventoAvisoListener eal;iterator i = listeners.listIterator(0);while (i.hasNext()) {

eal = (EventAvisoListener) i.next();eal.procesarAviso(ea);}

}public void actionPerformed(ActionEvent e) {

fireEventoAviso(new EventoAviso(this));JOptionPane.showMessageDialog(null, mensaje, "Aviso",JOptionPane.INFORMATION_MESSAGE);setActiva(false);

}// Resto de operaciones del bean...

}

interface EventoAvisoListener extends java.util.EventListener {public void procesarAviso(EventoAviso ev);

}

class EventoAviso extends java.util.EventObject {EventoAviso(Object s) {

super(s);}

}

Componentes visuales La mayoría de los componentes que se utilizan son

visuales, es decir, implementan elementos de la interfaz de usuario

Muchos de los elementos de Swing son componentes visuales

Construir un nuevo componente visual (basado en Swing) es muy sencillo: tan solo hay que construir una clase que herede de la clase JComponent o de cualquiera de sus descendientes


Vamos a construir un componente que funcione como un enlace a una página web. Es decir, cuando sea pulsado por el ratón lanzará una página determinada en el navegador web


import java.beans.*;import java.awt.*;import java.awt.event.*;import java.io.Serializable;import javax.swing.JLabel;import javax.swing.JOptionPane;public class URLLink extends JLabel implements Serializable {

private String URL;private String navegador;public class URLLinkMouseListener extends MouseAdapter {

public void mouseClicked(MouseEvent e) {irURL();

}}public URLLink() {

setURL("");setNavegador("");setText("URL"); // Texto por defecto del JLabelsetForeground(Color.blue); // Color del textosetCursor(new Cursor(Cursor.HAND_CURSOR)); // Cursor (mano apuntadora)setIcon(new javax.swing.ImageIcon("url.png")); // Triángulo azuladdMouseListener(new URLLinkMouseListener()); // Añadir listener

}


public String getURL() { // Propiedad URLreturn URL;

}public void setURL(String value) {

String aURL = URL;URL = value;

}public String getNavegador() { // Propiedad Navegador

return navegador;}public void setNavegador(String value) {

String aNavegador = navegador;navegador = value;

}public void irURL() {

try {Runtime.getRuntime().exec(navegador + " " + URL);

}catch (java.io.IOException e) {

JOptionPane.showMessageDialog(this, "No es posible ejecutar navegador","Error", JOptionPane.ERROR_MESSAGE);

}}

}

El componente hereda gran cantidad de propiedades y eventos de Jlabel


Descripción detallada de beans El mecanismo automático de introspección es suficiente para

que el entorno obtenga toda la información de propiedades y eventos del bean

Sin embargo hay otros aspectos adicionales no contemplados:El icono que va a representar el bean en la paleta La descripción de cada una de las propiedadesEspecificar qué propiedades deben ser

visualizadas/editables en el editor de propiedadesEl cuadro de propiedades tiene varios apartados:

propiedades principales, otras propiedades, layout, accesibilidad, etc. ¿Como asignar una propiedad a un apartado determinado, y como crear otros apartados?


Descripción detallada de beans Junto a un bean es posible crear una clase auxiliar

<NombreBean>BeanInfo que va a proporcionar toda esta información. Esta clase debe extender la clase base SimpleBeanInfo

NetBeans permite generar automáticamente esta clase y realizar gran parte de su configuración de manera interactiva


Ejemplo con JavaBeans (1/2)

// fichero btranslator.javapublic class btranslator { public String translate(String expr) { .... la implementación iría aquí ..... }}


Ejemplo con JavaBeans (2/2)// fichero beanscliente.javaimport java.beans.Beans;public class beanscliente extends Beans { public static void main (String args[]) { btranslator TX; String s = new String(args[1]); ClassLoader cl = null; //system loader by default try { TX = (btranslator)Beans.instantiate(cl,"btranslator"); System.out.println(s+"->"+TX.translate(s)); } catch (Exception e) { e.printStackTrace(); System.exit(1); } }}


Component Object Model Microsoft (Rogerson 1997, Box 1998) COM DCOM OLE ActiveX


COM Modelo de componentes de Microsoft, definiendo:

la creación de dichos componentes, la construcción de aplicaciones sobre ellos.

COM establece un estándar binario de interoperabilidad entre componentes (independencia de los lenguajes y plataformas).

COM se basa en la noción de interfaz:nivel conceptual: conjunto de funciones que

implementa una componente.nivel binario: puntero a una estructura en memoria,

compuesta por un puntero (Nodo) a un vector de punteros a funciones (virtual table -vtable-).


COM La representación binaria de un interfaz COM proviene de

la estructura interna que utiliza el compilador C++ de Microsoft para representar clases base abstractas:

A partir de este concepto de interfaz, COM define un estándar binario para la invocación de funciones.


COMPONENTE

Interfaz Nodo

...

Op1

Op2

OpN

COM Las interfaces COM son inmutables. Si se desea extender la funcionalidad de una interfaz se

debe definir una nueva interfaz. Cada componente puede tener varias interfaces:


IUnknown

IOleObject

IDataObject

IPersistStorage

IOleDocument

COM Creación de componentes a través de fábricas de clases

(Class Factories) Un servidor es un objeto binario ejecutable que

empaqueta un conjunto de fábricas de clases, junto con las implementaciones de sus componentes:servidores internos (in-process servers)servidores locales (local servers)servidores remotos (remote servers)

Reutilización: delegación y agregación Invocación dinámica de funciones (IDispatch)


.dll

.exe

DCOM Distributed COM: Extensión de COM para soportar

invocación remota de procedimientos entre clientes y servidores:proxies (apoderados)stubs (juntas)

Algunos servicios adicionales:seguridad,aceleración de las operaciones remotasdetección de fallos en las comunicaciones...


Herramientas COM La programación en COM es laboriosa. El compilador MIDL genera a partir de descripciones en

COM IDL, la información necesaria para que los componentes funcionen en un entorno COM.

Necesidad de herramientas:Visual C++

Aportación de servicios básicos (IDataObject):invocación dinámica, transferencia uniforme de datos,

etc.


OLE Object Linking and Embedding Estándar para documentos compuestos de Microsoft OLE es una colección de interfaces que permite el

desarrollo y ejecución de documentos compuestos. Contenedores: almacenan partes de distinta procedencia Servidores: modelan el contenido de los documentos La mayoría de las grandes aplicaciones de Microsoft son

contenedores y servidores a la vez:Word es un típico servidor, que permite la inserción de

documentos.


Active X Estándar de Microsoft para sus componentes visuales,

denominados controles. Granularidad diversa: de botones a hojas de cálculo. Los controles pueden residir en cualquier tipo de

documento.


Active X OCX VBX

La nueva arquitectura de MS MDCA (Microsoft Distributed Component Architecture) Estructurado en torno a Java, COM y DCOM. Ofrece servicios similares a los de CORBAservices. Comunicación asíncrona basada en Microsoft Message

Queue Server. COM+ es otra extensión de COM que resuelve algunas

deficiencias: recolección, gestión de referencias, ...


Enlaces de Interés Columna Beyond Objects, Software Development Magazine

http://www.sdmagazine.com/features/uml/beyondobjects/ RM-ODP: Open Distributed Processing Reference Model

http://uml.fsarch.com/RM-ODP/index.html OMG

http://www.omg.org Douglas Schmidt: Corba Documentation

http://www.cs.wustl.edu/~schmidt/corba.html Java Beans Spec

http://java.sun.com/products/javabeans/docs/spec.html .NET de Microsoft

http://www.microsoft.com/net/default.asp


Añadir JAR a paleta de NetBeans Para añadir un JAR a la paleta: En Netbeans ir a HERRAMIENTAS

> PALETA > COMPONENTES SWING


Añadir JAR a paleta de NetBeans Seleccionamos añadir JAR


Añadir JAR a paleta de NetBeans

Buscamos el fichero .JAR que queramos añadir a la paleta y pulsamos siguiente.



Seleccionamos los componentes a añadir y pulsamos siguientes.



Seleccionamos la categoría “Beans Personalizados” y pulsamos TERMINAR



Ya tenemos nuestro componente en la paleta.


Date post:	15-Dec-2014
Category:	Technology
Upload:	jose-benitez-andrades
View:	2,923 times
Download:	4 times

3.creacion de componentes visuales

Technology