Desarrollo de Software Basado
en Componentes
Expositores:
Soraya Raquel Ruiz Espinoza
Luis Enrique Guevara Acevedo
El resto…
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.
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.
¿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.
¿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.
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.
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.
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.
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
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.
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.
Acercamiento a Componentes
 Al ver a los componentes como proveedores de servicios
aparecen dos características criticas de 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.
Acercamiento a Componentes
Interfaces
 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.
DIFERENCIA ENTRE COMPONENTES
Y CLASES DE OBJETOS:
 DIFERENCIA
OBJETOS:
ENTRE
COMPONENTES
Y
CLASES
DE
 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.
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.
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
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
Descargar

Desarrollo de Software Basado en Componentes