2a Charla Dsia Componentes

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 software puede ser: Un componente de de software: 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 autocontenido 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 C2 la 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: C2 C1  ASCII  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

more

archivo

grep

archivo

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 Composición Modular Composición Orientada a Objetos Composición de Subsistemas Parametrización de Código Fuente

Documentos Compuestos Aplicaciones compuestas Ambientes Integrados 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 Lospaquete: paquetes de clases endel Java Reuso paquete: Definición 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

Objeto cliente

5) El talón devuelve los resultados al objeto cliente

Red

1) El objeto cliente 2) El talón comunica el invoca un método método invocado al esqueleto del OS

Talón del OS en IDL

ORB

Nivel Servidor

3) El esqueleto invoca el método del OS

Esqueleto del OS en IDL Objeto Servidor OS

4) El esqueleto comunica 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  El

desarrollo 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 Diseño del Dominio

Análisis del Dominio

Especificación de requerimentos

Diseño de la Arquitectura

modelos de análisis

Desarrollo de Componentes

diseños genéricos

Especificación De Componentes

Búsqueda de Componentes

componentes

Adapt / Des. Componentes

Integración de 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 Base de procesos los Componentes de la Ingeniería de Dominio. 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 S is te m a

P ru e b a s d e l S is te m a

D e s c u b r im . d e R e q u e r im .

P ro c e s o s G e r e n c ia le s

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

A n a l. & E s p e c . de R e q u e r im .

D is e ñ o d e l 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  



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 



incrementa la confiabilidad (% de errores presentes) mejora el rendimiento del componente en cada reutilización

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