Desarrollo de Software Basado en Componentes

1. Desarrollo de Software Basado en Componentes Expositores: Soraya Raquel Ruiz Espinoza Luis Enrique Guevara Acevedo El resto…

2. Introducción El explosivo crecimiento de Internet y la enorme variedad de información disponible por la red ha dado lugar a una nueva realidad, la convergencia de estas dos disciplinas. La rápida evolución de los sistemas de computadoras y de las tecnologías de última generación tiene que estar en constante sintonía con las demandas reales de los profesionales de desarrollo de software, organizaciones y empresas. El “desarrollo de software basado en componentes” (DSBC), es una disciplina muy reciente que describe, construye y utiliza técnicas software para la elaboración de sistemas abiertos y distribuidos.

3. Introducción Surge como una extensión del paradigma de desarrollo Orientado a Objetos y así también, se basa, y mantiene muchas de sus características principales, agregando la filosofía del “ensamblaje” de componentes de software independientes y previamente construidos y testeados, y extendiendo más aún el concepto de “reutilización” del software dentro de las aplicaciones, para reducir los costes, tiempos y esfuerzos de desarrollo del software, a la vez que ayuda a mejorar la fiabilidad, flexibilidad y la reutilización de la aplicación final.

4. ¿POR QUÉ SURGE ESTÁ METODOLOGÍA? La metodología de software basada en Componentes surgió a finales de los 90's como una aproximación basada en la reutilización al desarrollo de sistemas de software. El proceso de desarrollo de sistemas informáticos de empresa ha cambiado gradualmente en pocos años para pasar de un modelo centralizado y rígido, hacia un modelo descentralizado, abierto y distribuido. El sistema informático de una empresa —a nivel de recursos software, hardware y humanos— solía estar localizado en un mismo espacio geográfico, en un departamento o una sección de la empresa. Desde aquí, el equipo de profesionales, que tradicionalmente estaba compuesto por las categorías de analistas y programadores de sistemas, elaboraba las aplicaciones del sistema de información haciendo uso de conocimientos y prácticas tradicionales del proceso de ingeniería del software.

5. ¿POR QUÉ SURGE ESTÁ METODOLOGÍA? El concepto más importante que ha cambiado y sigue cambiando los procesos de ingeniería y reingeniería, es el concepto de «componente». Inicialmente este concepto surge ante la necesidad de reutilizar partes o módulos software existentes que podían ser utilizadas para la generación de nuevas extensiones de las aplicaciones, o para la generación de aplicaciones completas. Pero esto suponía un gran esfuerzo, pues había que localizar estas partes reutilizables y almacenarlas en repositorios especiales que más tarde pudieran ser consultadas en fase de diseño. Desde el punto de vista de la ingeniería del software, el término “componente” procede de las “técnicas orientadas a objetos, y de su necesidad para desarrollar sistemas abiertos.

6. CONCEPTOS BÁSICOS Como es una disciplina joven y aunque ha tenido un gran impulso en lo que es la vanguardia del desarrollo de software de hoy en día, aún se encuentra en continuo desarrollo y evolución; sin embargo, podemos destacar algunos de los conceptos que son pilares fundamentales y sientan las bases de esta metodología. Sistema de aplicación: conjunto de herramientas que permiten la creación e interconexión de componentes software, junto con una colección de servicios para facilitar las labores de los componentes que residen y se ejecutan en él. Un sistema se denomina independientemente extensible si puede ser dinámicamente extendido, y en donde pueden combinarse extensiones independientemente desarrolladas por distintas partes o entidades, sin conocimiento unas de otras.

7. CONCEPTOS BÁSICOS Sistema Abierto: Un sistema es abierto si es concurrente, independientemente extensible, y permite a componentes heterogéneos ingresar o abandonar el sistema de forma dinámica. Estas condiciones implican que los sistemas abiertos son inherentemente evolutivos, y que la vida de sus componentes es más corta que la del propio sistema. Así, la Programación Orientada a Objetos (POO) ha sido el sustento de la ingeniería del software para los sistemas cerrados. Sin embargo, se ha mostrado insuficiente al tratar de aplicar sus técnicas para el desarrollo de aplicaciones en entornos abiertos.

8. CONCEPTOS BÁSICOS Reutilizar un componente no significa usarlo más de una vez, sino que implica la capacidad del componente de ser utilizado en contextos distintos a aquellos para los que fue diseñado. La reutilización es un concepto más abarcativo que solo limitarse a la reutilización de código fuente: ella involucra el uso de otros elementos de software, tales como arquitecturas de software y soluciones diseños estructurales que han probado su utilidad en situaciones similares (“patrones de diseño”), e incluso partes enteras de programas se pueden reutilizar adaptándolas al proyecto específico que estamos desarrollando.

9. Acercamiento a Componentes Un componente es una unidad de software independiente que puede estar compuesta por otros componentes y que se utiliza para crear un sistema de software. Un componente es una pieza de código preelaborado que encapsula alguna funcionalidad expuesta a través de interfaces estándar. Es algo muy similar a lo que podemos observar en el equipo de música que tenemos en nuestra sala. Cada componente ha sido diseñado para acoplarse perfectamente con sus pares, las conexiones son estándar y el protocolo de comunicación está ya preestablecido. Al unirse las partes, obtenemos música

10. Acercamiento a Componentes El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo espiral. Conduce a la reutilización del software, y la reutilización proporciona beneficios a los ingenieros de software. Según estudios de reutilización, QSM Associates Informa que el ensamblaje de componentes lleva a una reducción del 70 % del ciclo de desarrollo y un 84% del coste del proyecto.

11. Acercamiento a Componentes se puede considerar a un componente como un proveedor de servicios independiente. Cuando un sistema necesita un servicio llama al componente que le proporcione dicho servicio sin tener en cuenta donde se esta ejecutando o que lenguaje se a utilizado para desarrollar el componente. Ej. Un componente que convierta un formato grafico a otro (Ej.: png a jpg) proporciona un servicio de conversión de datos.

12. Acercamiento a Componentes Al ver a los componentes como proveedores de servicios aparecen dos características criticasde un componente reutilizable: 1- Es una entidad ejecutable independiente. El código fuente no esta disponible, por lo que el componente no tiene que ser compilado antes de que sea usado por otros componentes del sistema. 2- Los servicios ofrecidos por componentes están disponibles a través de una interfaz, y todas las interacciones son a través de esa interfaz.

13. Acercamiento a ComponentesInterfaces Los componentes se definen por sus interfaces y puede considerarse que tienen dos interfaces relacionadas. 1- Interfaz que proporciona: Define los servicios que proporciona el componente, lo que se conoce como el API del componente. Define los métodos que pueden ser llamados por el usuario del componente. 2- Interfaz que requiere: Especifica que servicios son necesarios para que el componente funcione, estos son requeridos de otros componentes del sistema. Esto no altera la independencia del componente, debido a que los servicios que se requieren no son solicitados a un componente especifico.

14. DIFERENCIA ENTRE COMPONENTES Y CLASES DE OBJETOS: DIFERENCIA ENTRE COMPONENTES Y CLASES DE OBJETOS: 1- Los componentes son entidades desplegables: No son compilados, se instalan directamente en una plataforma de ejecución. Los métodos y atributos definidos en sus interfaces pueden ser accedidos por otros componentes. 2- Los componentes no definen tipos: Las clases definen un tipo de dato abstracto y los objetos son instancias de ese tipo. Un componente ya es una instancia.

15. DIFERENCIA ENTRE COMPONENTES Y CLASES DE OBJETOS: 3- Las implementaciones de los componentes son opacas: La implementación de componentes esta oculta para los usuarios. Los componentes se suelen entregar como unidades binarias de este modo el que lo adquiere no tiene acceso a la implementación. 4- Los componentes están estandarizados: Esto significa que los componentes deben ajustarse a un modelo que restringe su implementación, a diferencia de las clases de objetos que pueden implementarse de cualquier forma.

16. COMPONENTES COTS (COMMERCIAL-OFF-THE-SHELF) La mayoría de de las metodologías de reutilización no contemplan el uso de componentes comerciales ya existentes para el desarrollo de aplicaciones software. A estos tipos de software se los conoce con el nombre de “comerciales fuera de la plataforma” o componente COTS. El termino COTS hace referencia al software comercial desarrollado previamente por terceras partes, fuera de las estrategias de desarrollo y aplicadas durante todo el ciclo de vida del producto

17. COMPONENTES COTS (COMMERCIAL-OFF-THE-SHELF) Esta clase de componente software generalmente es adquirido en formato binario, sin posibilidad de tener acceso al código fuente y sin información adicional que ayude a los integradores en la selección correcta de los mismos. Esto impide pensar en tareas para la automatización de procesos