PROGRAMACION BASADA EN COMPONENTES by mercy2beans111

VIEWS: 573 PAGES: 54

									PROGRAMACION BASADA EN
     COMPONENTES

     Dr. Pedro Mejia Alvarez
     Claudia P. Garcia Zamora
      Samuel Garrido Daniel
    Parte 1


Introducción
      Capítulo 1: 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.
     Los componentes son para
           composició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.
     Los componentes son para
           composición (ii)
• 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)
        Hechos a la medida VS
         Software Estándar
El desarrollo tradicional de software se divide en dos partes:

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

2. Se compra software estándar y se parametriza para
   proporcionar una solución que está muy cerca de ser lo
   que requiere el cliente.
     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.
   Ventajas y desventajas de (ii):
 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.
   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.
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.
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.
Componentes: Unidades de Implementación
La unidad de implementación es algo más estático que un obj.;
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.
      Lecciones Aprendidas
•   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
      Lecciones Aprendidas (ii)
• 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.
     Capítulo 2: El mercado VS la
             teconologí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”
          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.
   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.
 El 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).
       Tabla 2.1 Productos ofrecidos en ComponentSource
Distribución de los componentes ofrecidos ComponentSource




             Figura 2.1: 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.
         Capítulo 3: 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.
    Extrema 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.
 Extrema importancia de los (cuasi)
           estándares(ii)
• 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.
  ¿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.
     Parte 2


Fundamentación
                Capítulo 4
   ¿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.
                      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 de implementación independiente.
• Es una unidad compuesta por terceras partes.
• No cuenta con un estado observable desde el exterior.
                Componente(ii)
• 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.
                Componente(iii)
• 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
                                  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.
                            Objeto(ii)
• 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.
         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.
       Dependencias del contexto
• Interfaces requeridas

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

• Plataforma (Hardware/Software)
                     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
    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).
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.),
Estados y Contratos del Componente(ii)

   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.
Estados y Contratos del Componente(iii)

   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.
Estados y Contratos del Componente(iv)

   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.
Estados y Contratos del Componente(v)

   Objeto Componente. Instancia de un componente
     ya
   instalado en el momento cuando este va a ser
     invocado para
   su utilización.
Estados y Contratos del Componente(vi)

   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.
              Capitulo 5
 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.
                Capitulo 5
   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.
 Programación Orientada a Componentes(ii)


• 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 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 estan combinadas
dentro de un programa en formato binario ejectuable.

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 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.
     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 costo 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.
      Otros conceptos básicos de POC


•   Componentes COTS
•   Composición tardía
•   Entornos
•   Eventos
•   Polimorfismo
•   Reflexión
           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
             Problemas de la POC


•   Clarividencia
•   Percepción del entorno
•   Falta de soporte formal
•   Interoperabilidad
       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.
      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
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.
Ingeniería de Software Basada en Componentes(ii)

                             Objetivos

    (1) Desarrollar sistemas a partir de componentes ya
        construidos.

    (2) Desarrollar componentes como entidades reusables.

    (3) Mantener y evolucionar el sistema a partir de la
        adaptación y reemplazo de sus componentes.
¿PREGUNTAS?

								
To top