Universidad de Los Andes

Facultad de Ingeniería
Escuela de Ingeniería de
Sistemas
Mérida

Desarrollo de Software Basado

en Componentes

Jonás A. Montilva C.
Prof. Titular
Departamento de Computación
 Contenidos

 Reutilización de software
 Activos y componentes de software reutilizable
 Características de los Componentes de Software
Reutilizable (CSR)
 La interfaz de un componente
 Mecanismos de composición de software
 El proceso de desarrollo de software basado en
CSR

2
 Definiciones de Reutilización de
Software
"Reutilización de software es el proceso de crear
sistemas de software a partir de software existente,
en lugar de desarrollarlo desde el comienzo"
(Sametinger, 1997)

La reutilización es un enfoque de desarrollo [de

software] que trata de maximizar el uso recurrente
de componentes de software existentes"
(Sommerville, 1995).

“La reutilización de software es el proceso de

implementar o actualizar sistemas de software
usando activos de software existentes” (Sodhi &
Sodhi, 1999)
3
 Reutilización de Software
La reutilización de software va más allá
de la reutilización de componentes de
software
 Involucra uso de otros elementos,
denominados activos de software, tales como:
 algoritmos,

 diseños,

 arquitecturas de software,
 planes,

 documentación y
 especificaciones de requerimientos

4
 Reutilización de Software
La reutilización de software es un
proceso de la Ingeniería de Software que
involucra el uso recurrente de activos de
software en:
 la especificación,
 el análisis,
 el diseño,
 la implementación y
 las pruebas de una aplicación o sistema de
software

5
 Efectividad de la Reutilización
de Software
Varios estudios han demostrado la efectividad de
la reutilización del software:
 40-60% del código fuente es reutilizable de una
aplicación a otra.
 Aproximadamente el 60% del diseño y del código de
aplicaciones administrativas es reutilizable.
 Aproximadamente el 75% de las funciones son comunes
a más de un programa.
 Sólo el 15% del código encontrado en muchos sistemas
es único y novedoso a una aplicación específica.
 El rango general de reuso potencial está entre el 15% y
el 85%.

6
 Efectividad de la Reutilización
de Software
La EAI (Enterprise Application Integración) es un
nuevo enfoque de reutilización de software
 Su objetivo es la integración de aplicaciones existentes
con el propósito de compartir datos y procesos
Forrester Research ha estimado que:
 Más del 30% de los gastos globales en TI ocurren en la
integración de aplicaciones existentes
 Mas del 35% del tiempo de desarrollo de aplicaciones se
invierte creando interfaces para integrar la aplicación en
desarrollo a otras existentes o a fuentes de datos
El Gartner Group ha estimado que en los próximos
años la mayoría de proyectos de software se
ejecutarán mediante la integración de aplicaciones
existentes en lugar del desarrollo de nuevas
aplicaciones

7
 Activos de software
¿Qué es un activo de software
reutilizable (ASR)?
 Son productos de software diseñados
expresamente para ser reutilizados en el
desarrollo de muchas aplicaciones

 Un activo
Un componente de de software puede
software: ser:
Una arquitectura de dominio
 Una especificación de  Un esquema de base de
requerimientos datos
 Un modelo o especificación  Una especificación de prueba
de diseño
 La documentación de un
 Un algoritmo sistema
 Un patrón de diseño  Un plan

8
 Definición de Componente de
Software
Un componente de software reutililizable
(CSR) es un artefacto de software auto-
contenido y claramente identificable que:
 ejecuta funciones específicas,
 tiene una interface clara a través de la cual se
integra a otros sistemas,
 tiene una documentación apropiada y

 tiene un status de reuso definido

Un componente de software reutilizable

puede ser:
 un módulo,
 una clase,

 un procedimiento o función,

 un subsistema,

 una aplicación

9
 Características de los CSR
Definición del CBDi Forum:
 “Un componente es una pieza de software que describe y/o
libera un conjunto de servicios que son usados sólo a través
de interfaces bien definidas”
Características esenciales de un CSR:
 Identificable
 Autocontenido
 Rastreable a través de su ciclo de desarrollo
 Reemplazable por otro componente
 Accesible solamente a través de su interfaz
 Inmutabilidad de sus servicios
 Documentación de sus servicios
 Mantenido sistemáticamente

10
 Características esenciales de un
CSR
Es identificable
 Debe tener una identificación clara y consistente que
facilite su catalogación y acceso
Es autocontenido
 Un componente no debe requerir la reutilización de otros
componentes para cumplir su función
 Si el componente requiere de otros, el conjunto de
componentes o funciones, visto como un todo, debe ser
considerado como un componente de más alto nivel
 P.ej., los paquetes en Java permiten agrupar varias clases en un
componente al cual se le asocia una funcionalidad bien
definida.
Es rastreable
 Debe retener su identidad y ser rastreable durante el ciclo
de desarrollo
11
 Características esenciales de un
CSR
Es reemplazable
 Puede ser reemplazado por una nueva versión o por otro
componente que proporcione los mismos servicios
Es accesible sólo a través de su interfaz
 Es accedido a través de una interfaz claramente definida
 La interfaz debe ser independiente de la implementación física
 debe ocultar los detalles de su diseño interno
Sus servicios son inmutables
 Los servicios que ofrece un componente a través de su
interfaz no deben variar
 La implementación física de estos servicios pueden ser
modificadas, pero no deben afectar la interfaz

12
 Características esenciales de un
CSR
Está documentado
 Debe tener una documentación adecuada que facilite:
 la recuperación del componente desde el repositorio,
 la evaluación del componente,

 su adaptación al nuevo ambiente y

 su integración con otros componentes del sistema en que se

reutiliza.
Es mantenido
 Debe ser mantenido para facilitar un reuso sistemático:
 Su estado de reuso debe contener información acerca de:
 quien es el propietario del componente,
 quien lo mantiene,
 a quien acudir cuando surjan problemas y
 cual es el estado de la calidad del componente.

13
 Características deseables de un
CSR
Es genérico
Su implementación física está oculta
Es independiente de otros componentes
Está encapsulado
Es independiente del lenguaje o a las
herramientas usadas en su desarrollo
Es independiente de la plataforma de
ejecución
Puede ser reusado dinámicamente
Está certificado

14
La interfaz de un componente

15
 La interfaz de un componente
Una interface determina la manera en que un componente se
reutiliza y como puede conectarse a otros componentes
Una interface define una operación o un conjunto de operaciones
llamadas servicios o responsabilidades

solicita un servicio

C1
Las interfaces son un aspecto fundamental en C2la composición de
componentes consume el servicio
 Por lo general un componente produce (exporta) un resultado que es
consumido (importado) por otro componente

16
 La interfaz de un componente
La naturaleza de la interfaz varia
dependiendo del lenguaje empleado para
implementar el componente
En lenguajes OO:
 las clases se diseñan de tal manera que la interfaz
sea visible y separada de la implementación de las
operaciones (métodos)
En lenguajes procedimentales:
 la interfaz se define a través de:
 La declaración de la función o procedimiento o
 El uso de variables globales

17
 La interfaz de un componente
Existen varios tipos de interfaz
 Interfaces de datos
 Interfaces gráficas
 Interfaces de programación

18
 Tipos de interfaces
Interfaces de datos:
 Empleadas en componentes E-P-S:
 Leen datos de Entrada, ejecutan un Proceso de
transformación de datos o cálculo y escriben
datos de Salida.
 Tipos más comunes de formatos de datos
empleados en la interfaz:
 ASCII C1 C2
 Bases de datos relacionales

BD

19
 Tipos de interfaces
Ejemplo de interfaz de datos:
 El mecanismo de conducto (pipe) de UNIX
 la
salida textual en ASCII de un componente
(llamado filtro) es la entrada del siguiente
componente.
 P.ej:    more *.tex | grep Java | wc -l

*.tex archivo archivo

more grep wc número

20
 Tipos de interfaces
Interfaces de programación:
 El mecanismo empleado es el API (Application
Programming Interface)
 establece la interacción entre dos aplicaciones con plataformas
iguales o diferentes.
 Un API es "un conjunto de subrutinas de interfaz o
llamadas a librerías que definen los métodos empleados
para que un programa pueda invocar servicios externos"
 Ejemplo: Las interfaces empleadas en  la librería de clases del
sistema en Java, la cual provee diferentes paquetes (java.lang,
java.util, java.io) que contienen clases de uso común.
 Cada paquete contiene una interfaz y una colección de clases.

21
 Composición de software
reutilizable

C1 C2

22
 Composición de software
La composición de software es "el proceso de
construir applicaciones mediante la
interconexión de componentes de software a
través de sus interfaces [de composición]".
Tipos de composición de software:
Composición Interna/Externa Computación Distribuida
Composición Textual Modelos de Objetos
Composición Funcional
Documentos Compuestos
Composición Modular
Aplicaciones compuestas
Composición Orientada a Objetos
Ambientes Integrados
Composición de Subsistemas
Parametrización de Código Fuente Composición en Plataformas
Abiertas

23
 Composición de software
Composición Orientada a Objetos:
 Basada en la reutilización de clases o tipos
escritos en un lenguaje OO
 Emplean varios mecanismos de reutilización:
herencia, delegación, polimorfismo y
encadenamiento dinámico
 Ejemplos de componentes OO:
 La colección de clases reutilizables del lenguaje
Eiffel
 La librería de clases GNU para C++

 La librería del sistema en el lenguaje Java

24
 Composición de software
Composición de Subsistemas
Un subsistema es una colección de módulos o clases
que tienen una funcionalidad bien definida, así como
interfaces de importación y exportación de clases o
módulos.
Ejemplo:del
Definición Lospaquete:
paquetes de clases
Reusoendel
Java
paquete:
package subsistemaES; import subsistemaE/S.*
import java.util.* class MiClase
... {...
public class C1 {...} C1 x = new C1(15, 20);
public class C2{...} ...}
...

25
 Composición de software
Arquitecturas de Objetos Distribuidos
 Fueron desarrolladas para facilitar la computación
distribuidas en sistemas heterogéneos
 Constituyen la base para la interoperabilidad de
componentes distribuidos en plataformas
heterogéneas
 Ejemplos:
 CORBA del consorcio OMG
 Component Object Model (COM) y DCOM (Distributed

COM) de Microsoft
 System Object Model (SOM) de IBM

 Enterprise JavaBeans de SUN

26
 Composición de software
Arquitecturas de Objetos Distribuidos (cont.)
 Corba (Common object request broker architecture) es una especificación
propuesta por el consorcio de industrias de software Object Management
Group (OMG)
 Corba se basa en la OO para definir un tipo de middleware que permite la
interoperabilidad de componentes almacenados en plataformas
heterogéneas a través de un bus de objetos (ORB)

27
 Composición de Software
¿Cómo trabajan los objetos distribuidos
en CORBA?
Nivel Cliente Red Nivel Servidor
1) El objeto cliente
2) El talón comunica el
invoca un método
método invocado al esqueleto 3) El esqueleto invoca
Objeto del OS el método del OS
cliente

Esqueleto del OS
en IDL
Talón
del OS en
ORB Objeto
5) El talón IDL Servidor
devuelve OS
los resultados al
4) El esqueleto comunica
objeto cliente
los valores de retorno

28
 Composición de software
Arquitecturas de Objetos Distribuidos (cont.)
 La composición de componentes en CORBA se logra a través de un
lenguaje denominado IDL (Interface Definition Language).
 IDL es un lenguaje declarativo que asegura la independencia de
lenguajes entre los diferentes componentes distribuidos.
 Se usa para definir la interface de cada componente y establecer la
correspondencia con el lenguaje de programación en el cual se ha
implementado cada componente
 C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, and IDLscript.
 La comunicación entre los componentes es responsabilidad del ORB
(Object Request Broker), quien se encarga de:
 encontrar las implementaciones de los métodos u operaciones requeridas
por un cliente,
 ejecutar el pre-procesamiento necesario y

 comunicar los datos requeridos

29
El proceso de desarrollo basado
en componentes

30
 El proceso de reutilización de
software
Los procesos de desarrollo basados en la
reutilización de software se clasifican en:

 Desarrollo de componentes de software reutilizable

 Adaptación o desarrollo de componentes con el propósito
expreso de ser reutilizados en futuras aplicaciones

 Desarrollo de software con reutilización de componentes

 Eldesarrollo de una nueva applicación involucra el reuso de
un conjunto de componentes existente

31
 El proceso de reutilización de
software
El modelo de procesos gemelos:

Ingeniería de Dominios
Análisis del Diseño del Desarrollo de
Dominio Dominio Componentes

modelos diseños componentes

Especificación
de genéricos
de requerimentos
análisis

Diseño de la Especificación Búsqueda de Adapt / Des. Integración de

Arquitectura De Componentes Componentes Componentes Componentes

Ingeniería de Aplicaciones
32
 El desarrollo de CSR

Desarrollo de componentes de software

reutilizable
 Su objetivo es producir repositorios de activos
o componentes de software reutilizables que
puedan ser reutilizados en el desarrollo de
software
 El desarrollo de componentes se lleva a cabo
a través de:
 la adaptación de componentes existentes o
 la creación de repositorios aplicando los
Base de procesos
de la Ingeniería de Dominio. Componentes

33
 El desarrollo de CSR
El proceso de adaptación de un componente de software:
 Generalización del nombre
El nombre del componente debe referirse a entidades genéricas del
dominio.
 Generalización de operaciones
 La funcionalidad del componente puede ser extendida agregando nuevas
operaciones
 Las operaciones específicas deben ser removidas

 Generalización de excepciones
 Las excepciones específicas de una aplicación deben ser removidas
 Los mecanismos de manejo de excepciones se agregan al componente
para incrementar su robustez.
 Certificación del componente
 El componente es certificado como un componente reutilizable.
 Involucra asegurar la calidad y confiabilidad del componente

34
 Reutilización de CSR
Desarrollo de software con reutilización de
componentes
 Es un enfoque de desarrollo de software que
 maximiza la reutilización de componentes software
existentes y/o
 reduce el número de componentes que requieren ser

desarrollados desde el comienzo

 Condiciones mínimas para la reutilización
 Existencia de repositorios o bases de componentes
reutilizables
 Los componentes son confiables y actuán de acuerdo a

sus especificaciones
 Los componentes están debidamente documentados

35
 P ro c e s o s d e
P o s t-D e s a rr.
El Método Watch
A n á lis is d e l
D o m in io

E n tre g a d e l D e s c u b r im . d e
S is te m a R e q u e r im .

A n a l. & E s p e c .
P ru e b a s d e l P ro c e s o s
de
S is te m a G e r e n c ia le s
R e q u e r im .

Im p le m e n t. d e l D is e ñ o d e l
S is te m a S is te m a

D is e ñ o d e
C o m p o n e n te s
36
 Las formas de reutilización de
CSR
Reutilización caja-negra:
 El componente es utilizado "tal como es", sin
modificaciones y sin que se requiera conocer los detalles
internos de su implementación
 El usuario del componente sólo requiere conocer la
funcionalidad del componente (qué hace) y como se usa (su
interfaz)
Reutilización caja-blanca:
 El componente puede ser modificado para adaptarlo a las
necesidades del sistema en el que se reutiliza
 Su implementación es visible y puede ser modificada por el
usuario.
 Se requiere un esfuerzo adicional al de la modificación del
componente:
 debe ser verificado una vez modificado
37
 Conclusiones
Los CSR son las unidades básicas de producción de
la nueva industria del software
La reutilización de componentes de software
impacta positivamente:
 la calidad del software producido
 incrementa la confiabilidad (% de errores presentes)
 mejora el rendimiento del componente en cada reutilización
 la productividad de los grupos de desarrollo
 reduce la cantidad de código que debe producirse
 reduce la redundancia de esfuerzo
 el tiempo de entrega
 reduce el tiempo de colocación del producto en el mercado
 los costos
 reduce los costos de desarrollo y mantenimiento de nuevas
aplicaciones

38
Fin de la conferencia

39