Creación de Componentes Visuales

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

Jose Alberto Benítez Andrades
jose@indipro.es
www.indipro.es
@indiproweb

Jose Alberto Benítez Andrades– jose@indipro.es - @indiproweb 1

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– jose@indipro.es - @jabenitez88 2

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

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


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


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


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


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


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.


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.


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)


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.


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.


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.


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.


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.


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.


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.


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


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.


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 sostenible
Tecnología perfecta sin ningún mercado será vana”


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.


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.


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


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.


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.


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.


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.


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.


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.


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
definida
 Se 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


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.


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


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


POC – OBJETO
“Un objeto es una unidad de instanciación con una identidad única, un
estado 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.

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.


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.


POC – Dependencias del contexto

 Interfaces requeridas

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

 Plataforma (Hardware/Software)


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


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


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.


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.


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.


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.


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.


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.


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.


POC – Otros conceptos básicos de POC

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


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


POC – Problemas de la POC

 Clarividencia
 Percepción del entorno
 Falta de soporte formal
 Interoperabilidad


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.


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


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.


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


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


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étodos
Publish-and-subscribe para los eventos
Mensajes asíncronos


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


RM-ODP
 RM-ODP: Modelo de referencia para el diseño de sistemas
abiertos y distribuidos
 Objetivo: hacer transparente al usuario la heterogeneidad
del:
hardware
sistemas operativos
redes
lenguajes de programación
bases de datos
tipos de gestión


RM-ODP
 RM-ODP se divide en:
Descripción general y recomendaciones de uso
Modelo descriptivo
Modelo prescriptivo
Semántica arquitectónica
 Conceptos fundamentales:
Transparencia
Perspectivas:
empresa, información, computacional, ingeniería, tecn
ológico
Funciones y servicios comunes
Corredor de servicios

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


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 usuarios
Facilita 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ón
Modelos orientado a objetos


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.


RM-ODP: VISTAS
 Punto de vista de ingeniería
Expresa la naturaleza distribuida del sistema
Declara las trasparencias que soporta la infraestructura
Especifica la asignación de nodos de procesamiento
Usa 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.


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 los
clientes
Réplica Oculta la existencia de réplicas de objetos que soporten estados o
servivios
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


RM-ODP: definiciones estándar de
objetos 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:
rpc
Interfaces asíncronas para señales
...


 En RM_ODP pueden indicarse las conformidades necesarias
 Categorías de conformidad
Programación: comportamiento tras interfaces software
Perceptual: interfaces de usuario externas al sistema
Interworking: entre implementaciones
Intercambio: de medios de almacenamiento externo
conformidad: cumplimiento de una restricción de la
especificación, por un producto o por una implementación


 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, Sur
veillance, and Reconnaissance Architecture Framework


RM-ODP
 Notaciones usadas en las vistas
UML
ODP IDL, similar al CORBA IDL, un estandar de especificación de
encapsulamientos de objetos, independiente de la plataforma de
middleware, y del LP


CORBA


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 objetos
Transparencia de la heterogeneidad, dispersión y activación de
objetos en sistemas abiertos y distribuidos


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 ORB
Lenguaje de Descripción de Interfaces (IDL)
Repositorios de interfaces
Adaptadores de objetos (OA)


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 solicitado
devolver el resultado al cliente
 El Adaptador de Objetos (OA) se encarga de ocultar la
implementación del objeto sirviente


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

Estructura básica de un ORB

Implementación
Cliente
Servidor
DII IDL Stub DSI IDLSkel

Adaptador de Objetos

Interfaz ORB
Object Request Broker


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)


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


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


Arquitectura OMA

Objetos y Facilidades Facilidades
Aplicaciones Verticales Horizontales

Object Request Broker

Servicios comunes
(CORBAservices)

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/IP
Protocolo recomendado por OMG
Cualquier ORB que proporcione pasarelas IIOP cumple
el estándar CORBA


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


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


Ejemplo de CORBA (1/4)
// fichero translator.idl
interface Translator {
string translate(in string frase);
};
$ idl translator.idl

//fichero Translator.java
//Generated by the OrbixWeb IDL compiler
public interface Translator
extends org.omg.CORBA.Object {
public String translate (String frase);
}

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


 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...");
}
}


 Para registrar el sirviente en el repositorio CORBA:
$ putit orbixtranslator -java orbixtranslator.class

 Código de un cliente
import 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]));
}
}


JAVA/RMI,
JAVABEANS


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


Java
 Java es un lenguaje
“simple, distribuido, interpretado, robusto, seguro, indepe
ndiente 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


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)


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.


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)


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
}


 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); }
}


 El cliente
public 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(); }
}


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 JDBC
Applets Servidores B.D.
Cliente: Aplicaciones Almacenamiento
Interfaces de persistente
usuario de 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.

Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88

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 Serializable
Expone una serie de propiedades que pueden ser leídas y
modificadas desde el entorno de desarrollo
Expone 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;
}

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() {
Propiedad Activa  return t.isRunning();
}
public void setMensaje(String aMensaje) {
mensaje = aMensaje;
}
public String getMensaje() {
Propiedad Mensaje  return mensaje;
}
public void setPeriodoSegs(int aPeriodoSegs) {
t.setInitialDelay(1000 * periodoSegs);
if (t.isRunning()) {
t.restart();
}
}
Propiedad Periodo  public int getPeriodoSegs() {
return periodoSegs;
}
}


 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>.class
Java-Bean: True

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

Name: TPAviso.class
Java-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


 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


 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


 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
evento
Definir 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;
listeners = new LinkedList();
}
public TPAviso(String aMensaje, int aPeriodoSegs) {
mensaje = aMensaje;
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 JLabel
setForeground(Color.blue); // Color del texto
setCursor(new Cursor(Cursor.HAND_CURSOR)); // Cursor (mano apuntadora)
setIcon(new javax.swing.ImageIcon("url.png")); // Triángulo azul
addMouseListener(new URLLinkMouseListener()); // Añadir listener
}

public String getURL() { // Propiedad URL
return 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 propiedades
Especificar qué propiedades deben ser
visualizadas/editables en el editor de propiedades
El 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.java
public class btranslator {
public String translate(String expr) {
.... la implementación iría aquí .....
}
}


Ejemplo con JavaBeans (2/2)
// fichero beanscliente.java
import 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:
Op1
Interfaz Nodo Op2

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


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) .dll
servidores locales (local servers)
.exe
servidores remotos (remote servers)
 Reutilización: delegación y agregación
 Invocación dinámica de funciones (IDispatch)


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 remotas
detecció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


 Seleccionamos añadir JAR



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


Creación de Componentes Visuales

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

Similaire à Creación de Componentes Visuales

Similaire à Creación de Componentes Visuales (20)

Dernier

Dernier (20)

Creación de Componentes Visuales