3.creacion de componentes visuales

5,677 views

Published on

Desarrollo de software basado en componentes. Reutilización del software. Beneficios
Concepto de componente: Características
Propiedades y atributos:
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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
5,677
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
227
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

3.creacion de componentes visuales

  1. 1. Desarrollo de interfaces: 3.Creación de Componentes Visuales Jose Alberto Benítez Andrades jose@indipro.es www.indipro.es @indiprowebJose Alberto Benítez Andrades– jose@indipro.es - @indiproweb 1
  2. 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– jose@indipro.es - @jabenitez88 2
  3. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 3
  4. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 4
  5. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 5
  6. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 6
  7. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 7
  8. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 8
  9. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 9
  10. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 10
  11. 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) Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 11
  12. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 12
  13. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 13
  14. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 14
  15. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 15
  16. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 16
  17. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 17
  18. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 18
  19. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 19
  20. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 20
  21. 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 sostenible Tecnología perfecta sin ningún mercado será vana” Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 21
  22. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 22
  23. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 23
  24. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 24
  25. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 25
  26. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 26
  27. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 27
  28. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 28
  29. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 29
  30. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 30
  31. 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 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 31
  32. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 32
  33. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 33
  34. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 34
  35. 35. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 35
  36. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 36
  37. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 37
  38. 38. POC – Dependencias del contexto  Interfaces requeridas  Entorno de componentes para el cuál esta preparado (COM, CORBA, .NET, J2EE).  Plataforma (Hardware/Software) Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 38
  39. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 39
  40. 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). Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 40
  41. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 41
  42. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 42
  43. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 43
  44. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 44
  45. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 45
  46. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 46
  47. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 47
  48. 48. POC – Otros conceptos básicos de POC  Componentes COTS  Composición tardía  Entornos  Eventos  Polimorfismo  Reflexión Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 48
  49. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 49
  50. 50. POC – Problemas de la POC  Clarividencia  Percepción del entorno  Falta de soporte formal  Interoperabilidad Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 50
  51. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 51
  52. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 52
  53. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 53
  54. 54. PROGRAMACIÓN, MODELOS YPLATAFORMAS DE COMPONENTES ( RM-ODP, Corba deOMG, JAVA, JAVA/RMI , JavaBeans y DCOM )Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 54
  55. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 55
  56. 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étodos Publish-and-subscribe para los eventos Mensajes asíncronos Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 56
  57. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 57
  58. 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: hardware sistemas operativos redes lenguajes de programación bases de datos tipos de gestiónJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 58
  59. 59. 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 serviciosJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 59
  60. 60. RM-ODP  Todas salvo la vista tecnológica son independientes de la implementaciónJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 60
  61. 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 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 objetosJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 61
  62. 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.Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 62
  63. 63. 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.Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 63
  64. 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ónicaAcceso Oculta diferencias en protocolos, representación de datos y mecanismo de invocaciónFallo Oculta fallos y recuperaciones de otros objetosUbicación Oculta el uso de información de localización y ligadura a objetosMigración Oculta las repercusiones del cambio de ubicación de un objeto sobre éste mismoReubicación Oculta cambios de la ubicación de una interface o un servicio de los clientesRéplica Oculta la existencia de réplicas de objetos que soporten estados o serviviosPersistencia Oculta la activación/desactivación de objetos (incluso del mismo objeto)Transacción Oculta la coordinación de actividades para lograr la consistencia Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 64
  65. 65. 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 ...Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 65
  66. 66. RM-ODP: definiciones estándar de objetos de infraestructura distribuidaJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 66
  67. 67. RM-ODP: definiciones estándar de objetos de infraestructura distribuida  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ónJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 67
  68. 68. RM-ODP: definiciones estándar de objetos de infraestructura distribuida  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 FrameworkJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 68
  69. 69. 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 LPJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 69
  70. 70. CORBAJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 70
  71. 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 objetos Transparencia de la heterogeneidad, dispersión y activación de objetos en sistemas abiertos y distribuidosJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 71
  72. 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 ORB Lenguaje de Descripción de Interfaces (IDL) Repositorios de interfaces Adaptadores de objetos (OA) Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 72
  73. 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 solicitado devolver el resultado al cliente  El Adaptador de Objetos (OA) se encarga de ocultar la implementación del objeto sirviente Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 73
  74. 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 solicitado devolver el resultado al cliente  El Adaptador de Objetos (OA) se encarga de ocultar la implementación del objeto sirviente Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 74
  75. 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). Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 75
  76. 76. Estructura básica de un ORB Implementación Cliente Servidor DII IDL Stub DSI IDLSkel Adaptador de Objetos Interfaz ORB Object Request Broker Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 76
  77. 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) Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 77
  78. 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, ... Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 78
  79. 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, ... Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 79
  80. 80. Arquitectura OMA Objetos y Facilidades Facilidades Aplicaciones Verticales Horizontales Object Request Broker Servicios comunes (CORBAservices) Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 80
  81. 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/IP Protocolo recomendado por OMG Cualquier ORB que proporcione pasarelas IIOP cumple el estándar CORBA Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 81
  82. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 82
  83. 83. Implementaciones de CORBA  Existen más de 25 implementaciones de CORBA  Orbix (Iona)  Object Broker (Digital)  Visibroker (Visigenic -Netscape)  Component Broker (IBM) Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 83
  84. 84. 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); } Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 84
  85. 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... } } Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 85
  86. 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..."); } } Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 86
  87. 87. Ejemplo de CORBA (4/4)  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])); } } Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 87
  88. 88. JAVA/RMI, JAVABEANSJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 88
  89. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 89
  90. 90. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 90
  91. 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) Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 91
  92. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 92
  93. 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) Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 93
  94. 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 } Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 94
  95. 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); } } Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 95
  96. 96. Ejemplo de Java/RMI (3/3)  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(); } } Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 96
  97. 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 JDBC Applets Servidores B.D. Cliente: Aplicaciones Almacenamiento Interfaces de persistente usuario de datos Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88 97
  98. 98. 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
  99. 99. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  100. 100. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  101. 101. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  102. 102.  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); }Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  103. 103.  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) { periodoSegs = aPeriodoSegs; t.setInitialDelay(1000 * periodoSegs); if (t.isRunning()) { t.restart(); } }Propiedad Periodo  public int getPeriodoSegs() { return periodoSegs; } }Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  104. 104.  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) {}; } }Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  105. 105.  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.classJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  106. 106.  Ya podemos instalar el bean en el netBeans (o cualquier otro entorno de desarrollo Java):Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  107. 107.  Y lo tendremos disponible en la paleta de componentes:Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  108. 108.  Podemos seleccionarlo y utilizarlo en la aplicación. Sus propiedades son editables de manera interactivaJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  109. 109.  netBeans se encarga de generar automáticamente el código de creación del componente y asignación de las propiedades:Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  110. 110. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  111. 111. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  112. 112. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  113. 113. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  114. 114. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  115. 115.  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); }Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  116. 116. 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); } }Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  117. 117. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  118. 118.  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 }Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  119. 119. 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); } } }Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  120. 120.  El componente hereda gran cantidad de propiedades y eventos de JlabelJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  121. 121. 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? Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  122. 122. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  123. 123. Ejemplo con JavaBeans (1/2) // fichero btranslator.java public class btranslator { public String translate(String expr) { .... la implementación iría aquí ..... } } Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  124. 124. 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); } } } Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  125. 125. Component Object Model  Microsoft (Rogerson 1997, Box 1998)  COM  DCOM  OLE  ActiveX Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  126. 126. 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-).Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  127. 127. 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.Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  128. 128. 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 IOleDocumentJose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  129. 129. 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)Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  130. 130. 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 ...Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  131. 131. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  132. 132. 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. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  133. 133. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  134. 134. 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, ... Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  135. 135. 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 Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  136. 136. Añadir JAR a paleta de NetBeans Para añadir un JAR a la paleta: En Netbeans ir a HERRAMIENTAS > PALETA > COMPONENTES SWING Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  137. 137. Añadir JAR a paleta de NetBeans Seleccionamos añadir JAR Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  138. 138. Añadir JAR a paleta de NetBeans Buscamos el fichero .JAR que queramos añadir a la paleta y pulsamos siguiente. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  139. 139. Añadir JAR a paleta de NetBeans Seleccionamos los componentes a añadir y pulsamos siguientes. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  140. 140. Añadir JAR a paleta de NetBeans Seleccionamos la categoría “Beans Personalizados ” y pulsamos TERMINAR Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88
  141. 141. Añadir JAR a paleta de NetBeans Ya tenemos nuestro componente en la paleta. Jose Alberto Benítez Andrades– jose@indipro.es - @jabenitez88

×