UNIVERSIDAD NACIONAL DEL SANTA

FACULTAD DE INGENIERÍA
Escuela Académico Profesional de Ingeniería de Sistemas e
Informática

CREACIÓN DE UNA LIBRERÍA DE NUEVOS COMPONENTES

REUTILIZABLES EN JAVA PARA MEJORAR LA CALIDAD DE
DESARROLLO DE SOFTWARE

Proyecto de Trabajo de Investigación

INVESTIGADOR:

BACH. Jonathan MUÑOZ ALEMAN

ASESOR:
ING. Sixto DÍAZ TELLO

NUEVO CHIMBOTE – PERÚ

Jueves, 25 de Junio de 2009
Índice de Contenidos
1. Datos Generales........................................................................................................................... 4
1.1. Título ................................................................................................................................... 4
1.2. Autor ................................................................................................................................... 4
1.3. Asesor.................................................................................................................................. 4
1.4. Tipo de Investigación .......................................................................................................... 4
1.5. Régimen de Investigación ................................................................................................... 4
1.6. Duración del Proyecto ......................................................................................................... 4
1.6.1. Fecha de Inicio: ........................................................................................................... 4
1.6.2. Fecha de Término: ....................................................................................................... 4
1.7. Área de Desarrollo del Proyecto ......................................................................................... 4
1.7.1. Localidad ..................................................................................................................... 4
1.7.2. Institución .................................................................................................................... 4
1.8. Unidad Académica .............................................................................................................. 4
1.9. Cronograma de Actividades a Desarrollar .......................................................................... 4
1.10. Recursos .......................................................................................................................... 5
1.10.1. Personal ....................................................................................................................... 5
1.10.2. Bienes y Materiales ..................................................................................................... 5
1.10.3. Servicios ...................................................................................................................... 5
1.11. Presupuesto...................................................................................................................... 6
1.11.1. Bienes y Materiales ..................................................................................................... 6
1.11.2. Servicios ...................................................................................................................... 6
1.11.3. Resumen ...................................................................................................................... 6
1.12. Financiamiento ................................................................................................................ 6
2. Plan de Investigación .................................................................................................................. 7
2.1. Problema ............................................................................................................................. 7
2.1.1. Realidad Problemática................................................................................................. 7
2.1.2. Análisis del Problema.................................................................................................. 8
2.1.3. Formulación del Problema .......................................................................................... 9
2.1.4. Antecedentes ............................................................................................................... 9
2.1.5. Justificación............................................................................................................... 10
2.1.6. Limitaciones .............................................................................................................. 11
2.2. Objetivos ........................................................................................................................... 11

2
 2.2.1. Objetivo General ....................................................................................................... 11
2.2.2. Objetivos Específicos ................................................................................................ 11
2.3. Hipótesis ............................................................................................................................ 11
2.4. Fundamento Teórico ......................................................................................................... 12
2.4.1. Desarrollo Basado en Componentes.......................................................................... 12
2.4.2. Lenguaje de Programación Java ................................................................................ 22
2.4.3. Especificación JavaBean ........................................................................................... 28
2.4.4. Tecnología ActiveX .................................................................................................. 31
2.5. Metodología a Seguir ........................................................................................................ 32
2.5.1. Análisis de Requerimientos ....................................................................................... 32
2.5.2. Diseño y Modelado de los Componentes .................................................................. 32
2.5.3. Desarrollo e Implementación .................................................................................... 32
2.5.4. Pruebas y Empaquetamiento ..................................................................................... 32
2.6. Diseño de Investigación .................................................................................................... 32
2.7. Cobertura del Estudio ........................................................................................................ 33
2.7.1. Población ................................................................................................................... 33
2.7.2. Muestra ...................................................................................................................... 33
2.8. Técnicas e Instrumentos de Recolección de Datos............................................................ 33
Bibliografía y Linkografía................................................................................................................. 33

Índice de Ilustraciones
Ilustración 1. Diagrama de Gantt con el cronograma de actividades. ................................................. 5

Índice de Tablas
Tabla 1. Presupuesto de bienes y materiales. ...................................................................................... 6
Tabla 2. Presupuesto de servicios. ...................................................................................................... 6
Tabla 3. Presupuesto total. .................................................................................................................. 6
Tabla 4. Variables e indicadores. ...................................................................................................... 12
Tabla 5. Diseño Experimental. .......................................................................................................... 32
Tabla 6. Técnicas e instrumentos de recolección de datos. ............................................................... 33

3
Proyecto de Trabajo de Investigación
1. Datos Generales
1.1. Título
CREACIÓN DE UNA LIBRERÍA DE NUEVOS COMPONENTES REUTILIZABLES
EN JAVA PARA MEJORAR LA CALIDAD DE DESARROLLO DE SOFTWARE

1.2. Autor
BACH: Jonathan MUÑOZ ALEMAN

1.3. Asesor
ING. Sixto DÍAZ TELLO

1.4. Tipo de Investigación

Aplicada/Tecnológica

1.5. Régimen de Investigación

Libre, el presente Plan de Trabajo de Investigación es realizado por iniciativa del autor.

1.6. Duración del Proyecto

1.6.1. Fecha de Inicio:
18/05/2009

1.6.2. Fecha de Término:

11/09/2009

1.7. Área de Desarrollo del Proyecto

1.7.1. Localidad
Nuevo Chimbote – Ancash – Perú

1.7.2. Institución
Universidad Nacional del Santa – Ancash

1.8. Unidad Académica

Facultad de Ingeniería – Escuela Académico Profesional de Ingeniería de Sistemas e
Informática

1.9. Cronograma de Actividades a Desarrollar

Para llevar a cabo el proyecto se hace necesario realizar diferentes actividades, las que serán
mostradas en el siguiente Diagrama de Gantt, donde se establecen tiempos aproximados
para el cumplimiento de dichas actividades.

4
 Las actividades realizadas para la culminación del proyecto son las siguientes:

Nombre de tarea
07 jun '09 14 jun '09 21 jun '09
D L M X J V S D L M X J V S D L M X J
Elaboración del PTI
Rev isión Bibliográfica
Recopilación de Inf ormación y Datos
Identif icación de la Problemática
Análisis de Requerimientos
Diseño y Modelado de Componentes
Desarrollo e Implementación
Pruebas y Empaquetación

Ilustración 1. Diagrama de Gantt con el cronograma de actividades.

1.10. Recursos
1.10.1. Personal
Investigador: Bach. Jonathan MUÑOZ ALEMAN
Asesor: ING. Sixto DÍAZ TELLO

1.10.2. Bienes y Materiales

Materiales de Escritorio
o Memoria Flash USB
o CD‘s
o Papel Bond
o Lapiceros

Equipos
o Computadora
o Impresora

1.10.3. Servicios
Internet
Movilidad

5
1.11. Presupuesto
1.11.1. Bienes y Materiales
ITEM Cant. Unidad Cost. Unit. Costo Total
MATERIALES DE ESCRITORIO
Memoria Flash USB 1 Unidad S/. 0.00 S/. 0.00
CD 1/2 Docena S/. 4.00 S/. 2.00
Papel Bond 1 Ciento S/. 3.50 S/. 3.50
Lapiceros 1/2 Docena S/. 3.00 S/. 1.50
EQUIPOS
Computadora 1 Unidad S/. 0.00 S/. 0.00
Impresora 1 Unidad S/. 0.00 S/. 0.00

Tabla 1. Presupuesto de bienes y materiales.

1.11.2. Servicios
SERVICIO Cant. Unidad Cost. Unit. Cost. Total
Internet 640 Horas S/. 1.00 S/. 640.00
Movilidad 80 Viajes S/. 1.00 S/. 80.00

Tabla 2. Presupuesto de servicios.

1.11.3. Resumen
ITEM TOTAL
Bienes y Materiales S/. 7.00
Materiales de escritorio S/. 7.00
Equipos S/. 0.00
Servicios S/. 720.00
Imprevistos S/. 72.70
TOTAL S/. 799.70

Tabla 3. Presupuesto total.

1.12. Financiamiento
El presupuesto del proyecto será financiado por el autor en su totalidad.

6
2. Plan de Investigación

2.1. Problema
2.1.1. Realidad Problemática
Los programadores procedentes del entorno Windows (en concreto Visual Basic o
PowerBuilder) sabrán inmediatamente por qué los componentes visuales reutilizables son
tan importantes. Los programadores procedentes de un entorno donde la tradición es
―volver a hacer lo mismo‖ para todas las cosas, pueden no entenderlo a la primera. Por
nuestra experiencia, los programadores que no proceden de Visual Basic, a menudo se les
hace duro entender que este lenguaje de programación es uno de los ejemplos más exitosos
de la tecnología de objetos reutilizables. Una de las razones de su popularidad se hace
evidente al considerar cómo se construye una aplicación en Visual Basic. Para quienes
nunca han trabajado con él, a continuación se tiene, en pocas palabras, cómo hacerlo:

1. La interfaz se construye arrastrando componentes (denominados controles) hasta una

ventana de formulario.
2. Mediante hojas de propiedades, se establecen las propiedades de los componentes,
como la altura y el color, entre otros comportamientos.
3. Las hojas de propiedades también enumeran los eventos ante los que los componentes
pueden reaccionar. Para algunos de estos eventos, se pueden escribir pequeños
fragmentos de código para manipular el evento.

Por ejemplo, para escribir un programa que visualiza una imagen en un marco en Java es
necesaria aproximadamente una página de código. A continuación se tiene lo que se debe
hacer en Visual Basic para crear un programa con la misma, o mayor, funcionalidad:

1. Añadir dos controles a una ventana: un control de imagen para visualizar gráficos y un
control de diálogo común para poder seleccionar un archivo.
2. Establecer la propiedad de filtro del control CommonDialog para que se visualicen
únicamente los archivos que el control de imagen puede manipular. Esto se hace en lo
que Visual Basic denomina ventana de propiedades.

A continuación, se debe escribir las tres líneas de código de Visual Basic que se activarán
cuando el proyecto empiece a ejecutarse. Esto corresponde a un evento denominado
Form_Load, de modo que el código va en el procedimiento del evento Form_Load. El
siguiente código despliega el cuadro de diálogo de manipulación de archivos (pero se
visualizan los archivos con la extensión correcta, debido a la definición de la propiedad de
filtro). Después de que el usuario selecciona un archivo de imagen, el código indica al
control Image que lo visualice. Todo el código que necesitamos para esta secuencia se
parece a éste:

Private Sub Form_Load()

On Error Resume Next
CommonDialog1.ShowOpen
Image1.Picture = LoadPicture(CommonDialog.FileName)
End Sub

7
 Esto es todo. La actividad de diseño en combinación con estas tres líneas de código,
proporcionan en esencia la misma funcionalidad que una página de código del lenguaje de
programación Java. Ciertamente, es mucho más fácil aprender a soltar componentes y
establecer propiedades que escribir una página de código.

La verdad es que ahora mismo el lenguaje de programación Java es todavía una herramienta
utilizada por la mayoría de los mejores programadores que se dedican a la programación
orientada a objetos. Y, ciertamente, es improbable que dichos programadores sean tan
productivos como un buen programador de Visual Basic a la hora de diseñar la interfaz de
usuario de una aplicación cliente.

Sin embargo Visual Basic es una buena solución para todos los problemas. Está claramente
optimizado para un tipo concreto de problemas: los programas de Windows fuertemente
orientados a la interfaz de usuario. Por el contrario, la tecnología Java siempre tendrá un
rango de usos mucho más amplio.

Con la llegada de la tecnología JavaBeans, algunas de las ventajas de la construcción de

aplicaciones al estilo de Visual Basic han sido conseguidas por los programadores. Esto se
debe a dos circunstancias:

Los beans tienen la misma funcionalidad que la mayoría de los controles comunes de
Visual Basic.
Las herramientas constructoras de la tecnología Java se han acercado mucho a la
facilidad de uso de entornos como Microsoft Visual Basic o PowerBuilder.

La definición oficial de un bean, como se indica en la especificación JavaBeans, es: ―un

componente software reutilizable basado en la especificación JavaBeans de Sun que puede
manipularse visualmente con una herramienta de desarrollo‖.

Una vez construido un bean, los usuarios de cualquier entorno que tengan habilitada la
tecnología JavaBeans pueden utilizarlo rápidamente. Los desarrolladores pueden, incluso, a
través de la magia de la tecnología puente ActiveX, desplegar JavaBeans en aplicaciones
Visual Basic y Microsoft Office. (Horstmann & Cornell, 2003)

2.1.2. Análisis del Problema

A pesar de la aparición de la especificación de la API JavaBeans en el año 1998; y de que, a
partir de ese año, los fabricantes de entornos de desarrollo existentes para el lenguaje Java
(como NetBeans™ o Eclipse™) han realizado grandes esfuerzos y avances para integrar de
manera cómoda esta tecnología en sus herramientas, el problema es que no se conoce de
alguna implementación de componentes beans que emulen la funcionalidad de los controles
existentes en otros entornos como Visual Basic o PowerBuilder.

Este problema tiene dos repercusiones en el desarrollo de aplicaciones basadas en interfaces

de usuario en Java:

8
 Un programador experimentado en entornos gráficos, como Visual Basic, que desea
incursionar en la tecnología Java, no encuentra las herramientas que le ofrecían los
entornos a los que estaba acostumbrado, y termina por confundirse y desanimarse.
Un desarrollador experto en tecnología Java desea disponer de componentes que le
eviten el trabajo de ―reinventar la rueda‖; y de esta manera también incrementar su
productividad y disminuir el tiempo y costos de desarrollo.

Una cosa que se debe recordar es que los componentes para interfaces de usuario son
bastante elaborados y complejos de codificar. Esto se debe a dos razones:

1. Los componentes deben ser funcionales para los programadores inexpertos. Dichos
programadores accederán a la funcionalidad del componente con una herramienta
visual con la que no es necesario programar. Se debe proporcionar un montón de
propiedades para facilitar la personalización del comportamiento del componente.

2. El mismo componente debe poder ser utilizado en una amplia gama de contextos. Un
componente demasiado simplista para su uso en el mundo real no conseguirá mucho
respaldo. Como es lógico, ésta es la razón por la que muchas personas pueden cobrar
cientos de soles, dólares o euros por un componente profesional, como un control para
generar gráficos con todas sus características. Por ejemplo, en el momento de escribir
esta tesis, un control convencional para generar gráficos tiene:
60 propiedades 47 eventos
14 métodos 178 páginas de documentación
Es una complejidad obviamente práctica y algo que uno no querría programar desde el
principio. Desarrollando una librería de componentes como éste, otros podrán beneficiarse
de este trabajo, simplemente soltando el componente en una herramienta de desarrollo.

Evidentemente, un gráfico o un calendario es un componente tan repleto de funcionalidades

como uno pueda imaginar, pero, incluso, un componente tan simple como un campo de
texto para introducir números podrá no resultar tan sencillo de codificar como cabría
esperar en un principio.

Por fortuna, sólo se debe dominar una pequeña cantidad de conceptos para escribir
componentes beans con un buen conjunto de comportamientos. Los beans de la librería que
se va a desarrollar, aunque no triviales, son suficientemente complejos para satisfacer las
necesidades expuestas. (Horstmann & Cornell, 2003)

2.1.3. Formulación del Problema

¿De qué manera la creación de una librería de nuevos componentes reutilizables en java
mejora la calidad de desarrollo de software?

2.1.4. Antecedentes
En la actualidad, existen en el mercado y en Internet una gran variedad de componentes y
herramientas desarrolladas en lenguaje Java que son utilizadas por millones de
programadores alrededor del mundo en proyectos de software de múltiple envergadura.

9
 Algunas de ellas son de libre distribución y otras son comerciales regidas por su copyright.
A continuación se cita algunas de ellas:

JFreeChart es una librería de gráficos que soporta gráficos circulares (2D y 3D),
gráficos de barras (horizontales y verticales, regulares y apiladas), gráficos de línea,
dispersos, de series de tiempo, diagramas de Gantt, gráficos combinados, termómetros,
discos y más. JFreeChart puede ser usado en aplicaciones, applets, servlets y JSP. Este
proyecto es mantenido por David Gilbert. (Gilbert & Morgner)
La herramienta iReport es un constructor/diseñador de informes visual, poderoso,
intuitivo y fácil de usar para JasperReports escrito en Java. Este instrumento permite
que los usuarios corrijan visualmente informes complejos como cartas, imágenes,
subinformes, etc. iReport está además integrado con JFreeChart. Los datos para
imprimir pueden ser recuperados por varios caminos incluso múltiples uniones JDBC,
TableModels, JavaBeans, XML, etc. (Jaspersoft)
PDFOne Java es una poderosa biblioteca para la creación y administración de archivos
PDF para la plataforma Java. PDFOne Java admite la creación, llenado y lectura de
formularios PDF, compresión, protección, anexión y fusión de múltiples documentos
PDF, sellado, construcción de tabla de contenidos, establecimiento de señales de
lectura y muchas más funciones que pueden ser realizadas sobre documentos PDF.
(Gnostice Information Technologies)
jPDFViewer es un Bean Java que se puede agregar a aplicaciones Java para visualizar
documentos PDF. Con PDFViewer, se puede entregar contenido a los usuarios a través
de una aplicación sin la necesidad de instalar otros programas. jPDFViewer es
independiente de plataformas, por lo tanto puede ser usado en cualquier ambiente que
admita Java, incluyendo Windows, Mac OSX y Linux. (Qoppa Software)
2D/3D Vertical Bar Graph API Library es un componente Java Bean diseñado
específicamente para permitir a los programadores agregar fácilmente poderosa
funcionalidad de generación de gráficos a cualquier tipo de aplicación Java.
(jPowered.com)
Barcode for Java es una biblioteca desarrollada en este lenguaje para crear códigos de
barras. Es compatible con Linear, PDF417, DataMatrix y MaxiCode.
(BarcodeLib.com)

SetVB2Java es una DLL con la que se pueden convertir formularios hechos en Visual Basic
a código Java. El inconveniente con esta solución es que se necesita utilizar previamente el
entorno de Visual Basic para diseñar el formulario, convertirlo con la librería y utilizar el
código generado en una herramienta de desarrollo para Java. Este proceso es inviable.

Alternativamente, existen librerías que extienden el conjunto de componentes estándar

visuales de Java, pero que sólo ofrecen nuevos aspectos a los usuarios. Por lo tanto, se
puede considerar el proyecto a desarrollar como novedoso e innovador.

2.1.5. Justificación
Es bien sabido que el lenguaje Java y toda la tecnología que orbita a su alrededor generó,
desde el principio, una gran expectativa en la industria del software, debido a sus

10
 características y promesas. Hoy en día, esta tecnología está bastante madura y desarrollada,
además de estar presente en todo lugar, desde pequeños dispositivos móviles, servidores
empresariales y supercomputadoras científicas.

A pesar de no contar con los recursos con los que cuenta una empresa de software, resulta
cómodo y sencillo desarrollar nuevas herramientas basadas en este lenguaje, las cuales
llevarán a la tan ansiada conectividad absoluta.

Es por esta razón que el desarrollo de este proyecto sugiere un gran avance en lo que
respecta a desarrollo rápido de aplicaciones basadas en interfaces de usuario.

El presente trabajo de investigación se realiza con la finalidad de hacer del desarrollo de

software en Java una actividad cada vez más dinámica y sencilla, beneficiando a
programadores y equipos de desarrollo en todo el mundo.

Se desea también poder realizar un aporte a la comunidad de software libre, agregando esta
herramienta al espectro de aplicaciones que abundan en Internet.

2.1.6. Limitaciones
El proyecto está limitado a realizar una librería de componentes visuales y no visuales
desarrollados en el lenguaje Java. EL software se distribuirá bajo la licencia GNU GPL, por
lo tanto, se pondrá a disposición la librería, el código fuente, la documentación HTML y un
manual de usuario.

2.2. Objetivos
2.2.1. Objetivo General
Crear una librería de nuevos componentes reutilizables en Java para mejorar la calidad de
desarrollo de software.

2.2.2. Objetivos Específicos

Desarrollar componentes visuales reutilizables escritos en Java que sean equivalentes a
los controles utilizados en Visual Basic y PowerBuilder.
Desarrollar componentes no visuales reutilizables que implementen operaciones de
propósito general.
Aplicar patrones de diseño apropiados y comprobados en la construcción de los
componentes de la librería.
Demostrar que los estudiantes de la Universidad Nacional del Santa también podemos
desarrollar herramientas de software para terceros.

2.3. Hipótesis
La creación de una librería de nuevos componentes reutilizables en Java mejorará la calidad
de desarrollo de software.

Variables Indicadores
VI: Librería de nuevos Número de componentes desarrollados
componentes reutilizables en Java Número de propiedades de los componente

11
 Tiempo de desarrollo de software
VD: La calidad de desarrollo de
Número de líneas de código escritas.
software
Costo de desarrollo
Tabla 4. Variables e indicadores.

2.4. Fundamento Teórico

2.4.1. Desarrollo Basado en Componentes
Los continuos avances en la Informática y las Telecomunicaciones están haciendo cambiar
la forma en la que se desarrollan actualmente las aplicaciones software. En particular, el
incesante aumento de la potencia de los ordenadores personales, el abaratamiento de los
costes del hardware y las comunicaciones, y la aparición de redes de datos de cobertura
global han disparado el uso de los sistemas abiertos y distribuidos. Esto ha provocado, entre
otras cosas, que los modelos de programación existentes se vean desbordados, siendo
incapaces de manejar de forma natural la complejidad de los requisitos que se les exigen
para ese tipo de sistemas. Comienzan a aparecer por tanto nuevos paradigmas de
programación, como pueden ser la coordinación, la programación orientada a componentes,
o la movilidad, que persiguen una mejora en los procesos de construcción de aplicaciones
software. En ellos se trabaja tanto en extensiones de los modelos existentes como en nuevos
modelos, en la estandarización de sus interfaces y servicios, y la pertinaz búsqueda del cada
vez más necesario mercado global de componentes software. Estos son parte de los nuevos
retos con los que se enfrenta actualmente la ingeniería del software.

Uno de los enfoques en los que actualmente se trabaja constituye lo que se conoce como
Desarrollo de Software Basado en Componentes (DSBC), que trata de sentar las bases para
el diseño y desarrollo de aplicaciones distribuidas basadas en componentes software
reutilizables. Dicha disciplina cuenta actualmente con un creciente interés, tanto desde el
punto de vista académico como desde el industrial, en donde la demanda de estos temas es
cada día mayor.

Las siguientes secciones pretenden servir como una breve introducción a algunos de los
conceptos y métodos fundamentales sobre los que se apoya el DSBC. En particular, se
hablará de las arquitecturas software y los marcos de trabajo, la programación orientada a
componentes, y en las plataformas de componentes distribuidas.

A. Conceptos Básicos
En primer lugar, se entiende por sistema a un conjunto de mecanismos y 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.

Un sistema es abierto si es concurrente, reactivo, 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

12
de sus componentes es más corta que la del propio sistema. No se desea incluir en la
definición de sistema abierto la propiedad de ser distribuido, puesto que se considera que
ambas características son independientes entre sí. Sin embargo, los sistemas objeto del
presente estudio comprenden ambas propiedades, siendo tanto abiertos como distribuidos.

Como consecuencia de dichas características, el desarrollo de aplicaciones para este tipo de

sistemas se ve afectado por una serie de problemas específicos, como son la gestión de la
evolución del propio sistema y de sus componentes, la falta de una visión global del
sistema, la dificultad para garantizar la seguridad y confidencialidad de los mensajes, la
heterogeneidad de los componentes, o su dispersión, lo que puede implicar retrasos y
errores en las comunicaciones.

El tratamiento de estas situaciones es lo que ha hecho ver la necesidad de nuevos modelos,

pues la programación tradicional se ha visto incapaz de tratarlos de una forma natural. 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. En particular, se ha
observado que no permite expresar claramente la distinción entre los aspectos
computacionales y meramente composicionales de la aplicación, y que hace prevalecer la
visión de objeto sobre la de componente, estos últimos como unidades de composición
independientes de las aplicaciones. Asimismo, tampoco tiene en cuenta los factores de
mercadotecnia necesarios en un mundo real, como la distribución, adquisición e
incorporación de componentes a los sistemas.

A partir de estas ideas nace la programación orientada a componentes (POC) como una
extensión natural de la orientación a objetos para los entornos abiertos. Este paradigma
propugna el desarrollo y utilización de componentes reutilizables dentro de lo que sería un
mercado global de software.

Sin embargo, disponer de componentes no es suficiente tampoco, a menos que seamos

capaces de reutilizarlos. Y 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. En este sentido, uno de los sueños que siempre ha tenido la
ingeniería del software es el de contar con un mercado global de componentes, al igual que
o curre con otras ingenierías, o incluso con el hardware. De hecho, la analogía con los
circuitos integrados (IC) llegó a poner de moda los términos software IC, software bus y
software backplane, aunque nunca se haya podido llegar más allá de la definición de estos
conceptos.

Para hablar de la existencia de un mercado de componentes software es necesario que los

componentes estén empaquetados de forma que permitan su distribución y composición con
otros componentes, especialmente con aquellos desarrollados por terceras partes. Esto nos
lleva a la definición de componente:

―Un componente es una unidad de composición de aplicaciones software, que posee un

conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado,

13
adquirido, incorporado al sistema y compuesto con otros componentes de forma
independiente, en tiempo y espacio‖

Las interfaces de un componente determinan tanto las operaciones que el componente

implementa como las que precisa utilizar de otros componentes durante su ejecución. Y los
requisitos determinan las necesidades del componente en cuanto a recursos, como por
ejemplo las plataformas de ejecución que necesita para funcionar. Obsérvese que los
conceptos de objeto y componente son ortogonales, y que ninguno de los dos depende del
otro.

Finalmente, a partir de los componentes reutilizables dentro de un mercado global de

software nace el concepto fundamental en estos entornos, el de componente COTS
(commercial off-the-shelf). Este concepto va a cambiar la idea tradicional del desarrollo de
software en donde todo es propietario —o la reutilización se reduce a un ámbito local (el de
la empresa que desarrolla el software)—, hacia nuevas metodologías de desarrollo de
software en donde es posible contar con elementos externos. Esto se va a traducir, como
veremos en la última sección, no sólo en nuevas formas de desarrollo e implementación de
aplicaciones, sino también en alteraciones durante las fases de especificación y diseño para
tener en cuenta este tipo de elementos. Aparecen también nuevos problemas, como el de la
búsqueda y reconocimiento de los componentes que se necesitan, su posible adaptación, o
la resolución de solapamientos entre las funciones y servicios que ofrecen.

Una vez disponemos del concepto de componente, un modelo de componentes define la

forma de sus interfaces y los mecanismos para interconectarlos entre ellos (p.e. COM,
JavaBeans o CORBA). Basada en un modelo de componentes concreto, una plataforma de
componentes es un entorno de desarrollo y de ejecución de componentes que permite aislar
la mayor parte de las dificultades conceptuales y técnicas que conlleva la construcción de
aplicaciones basadas en los componentes de ese modelo. En este sentido, p o demos definir
una plataforma como una implementación de los mecanismos del modelo, junto con una
serie de herramientas asociadas. Ejemplos de estas plataformas son ActiveX/OLE,
Enterprise Beans y Orbix, que se apoyan en los modelos de componentes COM, JavaBeans
y CORBA, respectivamente.

Por otro lado, un mercado global necesita también de estándares que garanticen la
interoperabilidad de los componentes a la hora de construir aplicaciones. En el mundo de
los sistemas abiertos y distribuidos estamos presenciando la clásica ‗guerra‘ de estándares
que sucede antes de la maduración de cualquier mercado. Todos los fabricantes y
vendedores de sistemas tratan de convertir sus mecanismos en estándares, a la vez que
pertenecen a varios consorcios que también tratan de definir estándares, pero de forma
independiente. Pensemos por ejemplo en Sun, que intenta imponer JavaBeans como modelo
de componentes, mientras que participa junto con otras empresas en el desarrollo de los
estándares de CORBA. Actualmente la interoperabilidad se resuelve mediante pasarelas
(bridges) entre unos modelos y otros, componentes especiales que se encargan de servir de
conexión entre los distintos componentes heterogéneos. La mayoría de los modelos
comerciales ofrecen pasarelas hacia el resto, pues reconocen la necesidad de ser abiertos.

14
B. Arquitecturas Software y Marcos de Trabajo
El disponer de componentes software no es suficiente para desarrollar aplicaciones, ya
provengan éstos de un mercado global o sean desarrollados a medida para la aplicación. Un
aspecto crítico a la hora de construir sistemas complejos es el diseño de la estructura del
sistema, y por ello el estudio de la Arquitectura Software se ha convertido en una disciplina
de especial relevancia en la ingeniería del software.

Entendemos por Arquitectura Software la representación de alto nivel de la estructura de un

sistema o aplicación, que describe las partes que la integran, las interacciones entre ellas,
los patrones que supervisan su composición, y las restricciones a la hora de aplicar esos
patrones.

En general, dicha representación se va a realizar en términos de una colección de

componentes y de las interacciones que tienen lugar entre ellos. De esta forma aparecen las
arquitecturas basadas en componentes y conectores: los primeros se dedican a labores
computacionales, mientas que los conectores encapsulan los patrones de sincronización y
coordinación entre los componentes. Este tipo de arquitecturas son completamente
modulares y favorecen la reutilización de todos sus elementos, incluyendo los que definen
las distintas relaciones entre ellos.

Una arquitectura software viene determinada por las diferentes instancias de cada tipo de
componentes y conectores que la componen, y por una serie de enlaces (bindings)
específicos que definen la unión de todas ellas formando una estructura. A esta estructura se
le da el nombre de configuración, y suele considerarse insertada en una jerarquía, pues toda
entidad software, independientemente de su granularidad, dispone de una estructura que
puede ser descrita mediante una arquitectura software.

Cuando lo que interesa no es obtener una configuración concreta, sino extraer los patrones
genéricos que definen a una familia de sistemas, se habla de estilos arquitectónicos. La
definición de estilos tiene una gran importancia desde el punto de vista de la reutilización, y
es un aspecto fundamental en la arquitectura del software.

En general, la arquitectura software nace como una herramienta de alto nivel para cubrir
distintos objetivos, entre los que destacamos:

Comprender y manejar la estructura de las aplicaciones complejas.

Reutilizar dicha estructura (o partes de ella) para resolver problemas similares.
Planificar la evolución de la aplicación, identificando sus partes mutables e inmutables,
así como los costes de los posibles cambios.
Analizar la corrección de la aplicación, y su grado de cumplimiento respecto a los
requisitos iniciales (prestaciones o fiabilidad).
Permitir el estudio de alguna propiedad específica del dominio.

Se han propuesto diversos modelos de arquitecturas software usando componentes y

conectores que se basan en la especificación de la arquitectura del sistema. En esta línea po
demos citar los trabajos que parten del modelo inicial de Allen y Garlan, como UNICON,

15
 AESOP, Arwin, Executable Connectors y LEDA. Todos ellos comparten la misma visión
arquitectónica de los sistemas, aunque cada uno de ellos utilice notaciones y formalismos
diferentes.

C. Lenguajes de Descripción de Arquitecturas

Todas las propuestas mencionadas anteriormente utilizan los Lenguajes de Descripción de
Arquitecturas (LDAs) para expresar la estructura de las aplicaciones. Los LDAs
proporcionan los modelos, notaciones y herramientas que permiten describir los
componentes y conectores que forman una aplicación, así como sus enlaces específicos. Los
LDAs deben ser capaces de:

Gestionar los diseños a alto nivel, adaptarlos a implementaciones específicas, y

permitir la selección de patrones o paradigmas de arquitecturas especificados
previamente.
Representar nuevos patrones de arquitecturas y nuevas formas de interacción entre los
componentes, de forma que puedan ser reutilizados en diseños futuros.
Aportar un conjuntos de herramientas formales para demostrar propiedades sobre los
sistemas expresados en ese lenguaje (seguridad o de viveza, por ejemplo).
Aportar otro conjunto de herramientas de desarrollo para realizar implementaciones
parciales de los sistemas a partir de su descripción en un LDA concreto.

En cuanto al tipo de arquitectura que permiten describir los distintos LDAs, los hay que
sólo permiten las arquitecturas estáticas, en donde las conexiones entre los componentes no
varían a lo largo de la vida del sistema; la utilidad de dichos LDA estáticos se pone de
manifiesto para la descripción de sistemas hardware o sistemas eléctricos, aunque no se
muestran muy adecuados para sistemas abiertos. En este tipo de sistemas es preciso que los
LDAs permitan expresar los cambios en las conexiones e interacciones entre los
componentes en tiempo de ejecución, pues van a depender, por ejemplo, de los recursos
disponibles o del perfil de los usuarios. Los LDAs mencionados antes permiten la
descripción de arquitecturas dinámicas, así como Rapide.

Por otro lado, hay muchas propuestas a nivel de especificación de arquitecturas software
basadas en formalismos cuyos únicos objetivos son el prototipado rápido de aplicaciones y
la verificación formal de algunas de sus propiedades, entre los que podemos citar Wright y
ACME. Aunque las bondades de estas propuestas son innegables, la mayoría de ellas se
quedan a este nivel de diseño, no abordando la problemática de la generación de código a
partir de las especificaciones. De esta forma dejan una laguna importante en el ciclo de
desarrollo de las aplicaciones, perdiéndose la descomposición del sistema en componentes y
conectores cuando se llega al nivel de la implementación. Conseguir metodologías que
cubran todo el ciclo de vida de las aplicaciones a partir de su arquitectura software es otro
de los caminos de investigación abiertos actualmente.

Hasta ahora hemos hablado de LDAs de propósito general que, al menos en teoría, pueden
usarse para cualquier dominio de aplicación. Sin embargo, cada dominio tiene sus
peculiaridades específicas y de ahí surgen los Lenguajes para Dominios Específicos (LDEs),
que incorporan conceptos y funciones particulares de un dominio concreto como parte del

16
 propio lenguaje. Los LDEs proporcionan grandes ventajas al arquitecto de sistemas, entre
ellas su especialización y gran expresividad en su dominio de aplicación, aunque suelen
presentar un serio problema de extensibilidad: apenas aparece un nuevo concepto
relacionado con el dominio que no estaba previsto en el lengua je, éste deja de ser útil.

Además de los LDAs y LDEs, existen otras propuestas que, teniendo su mismo objetivo,
ofrecen un punto de vista más composicional que arquitectónico para la construcción de
sistemas basados en componentes. Nos referimos a los denominados Lenguajes
Composicionales. Un lenguaje composicional es una combinación entre un LDA y un
lenguaje de configuración (scripting language), que sirven como soporte para un entorno de
composición visual. Los diferentes estilos arquitectónicos se definen a niveles de
componentes y conectores, y la unión entre ellos (glue) se define mediante el lengua je de
configuración. El objetivo es definir, a partir de un lenguaje composicional, metodologías y
entornos de desarrollo de aplicaciones software. Aunque ya se conocen las características
que deben poseer estos lenguajes composicionales para su tratamiento en entornos
arquitectónicos, todavía no existe ninguno consolidado, siendo quizá Pict el primer intento.
Pict es un lengua je basado en π-cálculo que simplifica notablemente esta notación formal,
pero permite utilizar la mayor parte de sus ventajas. Piccola es una evolución de Pict
creado como lenguaje de configuración con tipos dinámicos. Piccola trata de resolver las
dos principales desventajas que ha mostrado Pict: su demasiado bajo nivel, y la ausencia de
hooks, necesarios para especializar componentes mediante técnicas de reutilización de caja
negra.

D. Marcos de Trabajo
La reutilización de arquitecturas software se define dentro un marco de trabajo ( framework,
o abreviadamente MT). En general, un MT se suele definir de la siguiente forma:

―Un MT es un diseño reutilizable de todo o parte de un sistema, representado por un

conjunto de clases abstractas y la forma en la cual sus instancias interactúan‖.

Otra forma de expresar este concepto es: ―Un MT es el esqueleto de una aplicación que
debe ser adaptado a necesidades concretas por el programador de la aplicación‖. En ambas
definiciones podemos ver que un MT encapsula el patrón de la arquitectura software de un
sistema o de alguna de sus partes, que puede además estar parcialmente instanciada. Las
principales ventajas que ofrecen los MT son la reducción del coste de los procesos de
desarrollo de aplicaciones software para dominios específicos, y la mejora de la calidad del
pro ducto final. Sin embargo, la utilización de MT presenta actualmente ciertas dificultades,
aunque se suelen englobar todas en lo que comúnmente se denomina el problema de la
documentación de un MT. Este problema combina las dificultades que presenta la
identificación del MT y de su utilización (reutilización). En primer lugar, el desarrollador de
una aplicación se enfrenta con la dificultad de que le es muy complicado, si no imposible,
decidir si un MT es el adecuado para resolver su problema, y hasta qué grado es capaz de
resolverlo. Y en segundo lugar, si realmente el MT es el apropiado, ha de saber cómo ha de
utilizarlo (acomodándolo, especializándolo y posiblemente extendiéndolo) para integrarlo
en su implementación concreta. A esa adaptación se le denomina comúnmente extensión
del MT, y constituye la forma de reutilización de los marcos de trabajo.

17
Usualmente los MT se extienden mediante los denominados puntos de entrada (hot spots o
hooks), componentes (o procedimientos) cuya implementación depende del sistema o
entorno final en el que se ejecuta la aplicación, y que permiten adaptarla. Dichos puntos de
entrada son definidos por el diseñador del MT, cuya arquitectura debe orientar para que
estos sean la forma natural de extensión del marco.

El problema de la documentación se debe principalmente a que no existe una forma clara de

especificar los marcos de trabajo. De hecho, la documentación de mayor parte de los MT
existentes no está unificada, es pobre, o bien se encuentra dispersa entre mucha literatura
heterogénea y dirigida a usuarios de muy distintos perfiles. La razón fundamental de estos
hechos es que los marcos de trabajos existentes han nacido normalmente como
generalización de aplicaciones ya realizadas, cuya estructura ha sido extraída y recompuesta
como un MT para su posterior reutilización. Y en cuanto a los MT de nueva creación, estos
se enfrentan a la falta de estandarización de su documentación, por lo que dependen en gran
medida de la voluntad y cono cimientos de sus desarrolladores.

Por tanto, sería preciso disponer de mecanismos y herramientas para describir de forma
unificada y completa la arquitectura de un MT, los problemas para los que está diseñado, y
la forma en la que hay que utilizarlo. Existen diferentes propuestas en este sentido, que
pasamos a describir.

En primer lugar, algunos autores proponen la construcción de entornos gráficos que

permiten ‗navegar‘ por la arquitectura del MT, consultando en cada uno de sus puntos la
información que el usuario considera relevante. La representación de la arquitectura se
realiza de forma gráfica, ya sea mediante grafos o mediante secuencias de mensajes. Estas
propuestas aportan un conocimiento más profundo del marco de trabajo, aunque no definen
una metodología que permita utilizar ese conocimiento para adaptar el MT a la nueva
aplicación. Su utilidad queda por tanto reducida a la fase de identificación del MT.

Los contratos de reutilización pueden ser también utilizados en estos entornos para definir
la forma en la que pueden cooperar los diseñadores del MT y los encargados de adaptarlo o
extenderlo. Este enfoque define la información necesaria para documentar adecuadamente
un MT. Así, se deben documentar cada una de las clases con sus métodos, indicando los
que se consideran puntos de entrada al MT, y las relaciones de herencia, composición, etc.
Por otro lado, las extensiones que se realicen a un MT deben documentarse siguiendo el
mismo método, incluyéndose en la documentación final.

Los Patrones de Diseño (Design Patterns) son otro enfoque muy útil tanto para diseñar la
arquitectura de un MT como para documentar el diseño realizado, según postulan diferentes
autores. Un patrón de diseño ofrece una solución abstracta a un problema de diseño que
aparece muy frecuentemente, expresada mediante un conjunto de relaciones e interacciones
entre componentes. Sobre los patrones de diseño se hablara con mayor detalle en el
siguiente apartado.

Finalmente, el uso de herramientas visuales es uno de los enfoques de mayor aceptación

actualmente. Dichas herramientas proporcionan notaciones visuales que permiten

18
 representar tanto a los componentes como a los conectores, y definir sus enlaces. Asimismo,
permiten agregar nuevos componentes y definir nuevas relaciones entre ellos. Las
principales ventajas de estas propuestas se basan en su facilidad de uso y la rapidez con la
que permiten identificar la adecuación de un MT a una aplicación concreta, así como los
trabajos necesarios para extenderlo y adaptarlo. Por otro lado, las principales desventajas
que poseen estos métodos provienen de que no suelen permitir ningún tipo de verificación
sobre el diseño realizado, puesto que no suelen poseer ningún tipo de lengua je que sirva de
soporte a la notación gráfica, y que permita especificar más formalmente la arquitectura de
la aplicación y verificar sus propiedades. La unión de este tipo de notaciones gráficas con
los LDAs descritos anteriormente es otro de los campos en donde se está trabajando
actualmente.

E. Patrones de Diseño
Los patrones de diseño (PD) aparecen tras la tesis de E. Gamma publicados en un libro que
recoge no sólo su definición, sino todo un catálogo de PDs aplicables a la programación
básica orientada a objetos, y que cubren la mayor parte de los pequeños problemas
recurrentes que se plantean en el desarrollo de cualquier programa.

El trabajo de Gamma ha sido extendido por distintos autores, y actualmente existen

numerosos catálogos de PDs aplicables a casi todas las disciplinas (programación,
enseñanza, negocios, etc.), en cuya construcción se trabaja de forma muy activa. Casi todo
el trabajo sobre PDs está tutorizado por un colectivo de investigadores y empresarios que se
reúnen de forma periódica en las conferencias PLoP.

Los patrones de diseño y los marcos de trabajo son disciplinas complementarias, y por lo
general un MT suele estar compuesto por una colección de PDs. En este sentido, los PDs
suelen ser de una granularidad menor que la de un MT.

Pero los PDs también presentan algunos inconvenientes. La propuesta de ―diseñar

documentando‖ se basa en que todo MT debe poder ser construido en base a PDs más o
menos conocidos o estándares. Sin embargo, esto no es siempre cierto, pues cada dominio
de aplicación presenta peculiaridades específicas, que deben ser abordadas de forma
particular. Otro de los inconvenientes de los PDs es su elevado número, que los está
haciendo inmanejables; por eso uno de los retos que también trata de abordar la comunidad
de PDs es su catalogación. Por otro lado, la complejidad de ciertos PDs que modelan
relaciones complicadas entre un gran número de componentes hacen difícil su comprensión
y entendimiento, y por tanto su uso. Y por último, tampoco está claramente definida la
composición de PDs, por lo que se hace compleja la reutilización de PDs para construir
arquitecturas en base a ellos.

F. Paradigmas de Programación para Sistemas Abiertos

Hasta ahora hemos considerado la construcción de aplicaciones software desde su
perspectiva arquitectónica, analizando su estructura y expresándola mediante LDAs que
permiten representar las abstracciones de las entidades que las componen y las relaciones
entre ellas. Sin embargo, existen otros enfoques no arquitectónicos basados en distintos
modelos y paradigmas de programación. Todos ellos persiguen el mismo objetivo, la

19
construcción de aplicaciones en sistemas abiertos y distribuidos, aunque cada uno trata de
realizarlo desde perspectivas diferentes.

Al principio sólo existía la programación secuencial, pues cada programa sólo se ejecutaba
en una máquina monoprocesador y aislada. Posteriormente aparecieron las máquinas
multiprocesador y los sistemas operativos multitarea, por lo que nacieron nuevos
paradigmas y mecanismos de programación. En este sentido, la programación concurrente
proporciona la noción de procesos, aportando una serie de primitivas para controlarlos y
algunos mecanismos de comunicación y sincronización. Dichos mecanismos pueden estar
basados en memoria compartida (semáforos y monitores) o en mensajes (rendez-vous y
RPCs). Por último aparece la programación distribuida, que comenzó a tomar auge cuando
la interconexión entre distintos computadores pudo hacerse de forma eficiente y económica.
Las primeras soluciones estaban basadas en una extensión de los mecanismos que ofrecía la
programación concurrente para tratar con los problemas de localización y dispersión que
presentan las aplicaciones distribuidas (sockets, XWindows, RPCs, etc.), pero en seguida se
vio que estas extensiones no eran suficientes. Incluso los paquetes comerciales existentes a
este nivel (PVM, MPI, Horus o ISIS) han probado su efectividad en cuanto a la
implementación de las aplicaciones, p ero no a la hora de diseñarlas.

En primer lugar, esas extensiones son de demasiado bajo nivel para permitir el diseño y
construcción de grandes aplicaciones distribuidas con el nivel de abstracción necesario. En
este sentido, la programación paralela había desarrollado algunos esquemas organizativos
(también llamados skeletons) de mayor nivel conceptual que los semáforos, monitores o
sockets, y que deberían poder expresarse a nivel de diseño: esquemas como maestro-
trabajadores o las granjas de procesos. Lo mismo o curre con los esquemas desarrollados
por la inteligencia artificial, como pueden ser las pizarras (blackboards) o las redes de
contratos.

En segundo lugar, los sistemas abiertos introducen la necesidad de integrar programas

heterogéneos para formar aplicaciones, así como de poder trabajar con aplicaciones ya
existentes (legacy systems).

Y por último, y desde un punto de vista formal, cierta propiedades del comportamiento
colectivo de los componentes (lo calidad, movilidad, seguridad, etc.) no son fácilmente
manejables utilizando las lógicas y semánticas desarrolladas para lenguajes concurrentes
convencionales.

Entre los principales modelos y paradigmas de programación que han surgido para el diseño
e implementación de aplicaciones para sistemas abiertos y distribuidos se encuentran, entre
otros la coordinación, los actores y la programación concurrente, la programación paralela
computacional, la reflexión y la meta-programación, la programación orientada a
componentes, la computación móvil, o los agentes.

Cada uno de estos paradigmas trata de solucionar los problemas mencionados anteriormente
desde un enfoque distinto, no existiendo ningún paradigma lo suficientemente general y
extendido como para abarcarlos todos. En esta lección vamos a centrarnos principalmente

20
 en la programación orientada a componentes (POC), los problemas que trata de solucionar,
los conceptos sobre los que se fundamenta, y los mecanismos que ofrece.

G. La Programación Orientada a Componentes

La Programación Orientada a Componentes (POC) aparece como una variante natural de la
programación orientada a objetos (POO) para los sistemas abiertos, en donde la POO
presenta algunas limitaciones; por ejemplo, la POO no permite expresar claramente la
distinción entre los aspectos computacionales y meramente composicionales de la
aplicación, no define una unidad concreta de composición independiente de las aplicaciones
(los objetos no lo son, claramente), y define interfaces de demasiado bajo nivel como para
que sirvan de contratos entre las distintas partes que deseen reutilizar objetos.

La POC nace con el objetivo de construir un mercado global de componentes software,

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.

Las entidades básicas de la POC son los componentes, en el mismo sentido que se ha
definido, cajas negras que encapsulan cierta funcionalidad y que son diseñadas para formar
parte de ese mercado global de componentes, sin saber ni quién los utilizará, ni cómo, ni
cuándo. Los usuarios conocen acerca de los servicios que ofrecen los componentes a través
de sus interfaces y requisitos, pero normalmente ni quieren ni pueden modificar su
implementación.

En el contexto de este documento se considera a la POC como un paradigma de

programación que se centra en el diseño e implementación de componentes, y en particular
en los conceptos de encapsulación, polimorfismo, composición tardía y seguridad. No
discutiremos aquí sin embargo otros aspectos de marketing que lleva aso ciado un mercado
de componentes software, como cualquier otro mercado: distribución, comercialización,
empaquetamiento, almacenamiento, publicidad, licencias, etc. Aunque son de especial
relevancia para la POC, hemos preferido centrarnos solamente en los aspectos de técnicos
de desarrollo y utilización de los componentes software.

H. Modelos y Plataformas de Componentes

Más que a describir los principales modelos, plataformas, y marcos de trabajo para
componentes (PCD) que existen hoy en día, se ha preferido discutir las principales
características que distinguen a las plataformas de componentes, abstrayendo sus elementos
y servicios comunes con independencia de cómo se implementan en cada PCD particular.

Como se mencionó, un Modelo de Componentes es un estándar que define los interfaces de

los componentes y los mecanismos para interconectarlos entre ellos, mientras que un Marco
de Trabajo Distribuido es un MT diseñado para integrar componentes y aplicaciones
software en ambientes distribuidos, permitiendo la modularidad y reutilización en el
desarrollo de nuevas aplicaciones. En la terminología de la programación orientada a
componentes, este término es sinónimo de Plataforma de Componentes Distribuidos (PCD).
Este tipo de marcos ofrecen un entorno de desarrollo y de ejecución de componentes

21
 software que permite aislar la mayor parte de las dificultades conceptuales y técnicas que
conlleva la construcción de aplicaciones basadas en componentes. Cada plataforma se
apoya en los estándares y mecanismos definidos por su modelo de componentes base; en
este sentido, podemos definir una plataforma como una implementación de los mecanismos
del modelo, junto con una serie de herramientas aso ciadas. Ejemplos de estas plataformas
son ActiveX/OLE, Enterprise Beans y Orbix, que se apoyan en los modelos de
componentes COM, JavaBeans y CORBA, respectivamente.

Las plataformas de componentes distribuidos se apoyan sobre una serie de conceptos

básicos: los componentes, sus interfaces, los contenedores, la meta-información, los
servicios disponibles y los entornos de desarrollo integrados que proporcionan para
desarrollar componentes. Todas las plataformas incorporan estos conceptos y ofrecen esos
servicios a sus componentes, aunque fundamentalmente lo único que varía es la forma en la
que los implementan.

2.4.2. Lenguaje de Programación Java

Java es un lenguaje de programación orientado a objetos desarrollado por Sun
Microsystems a principios de los años 90. El lenguaje en sí mismo toma mucha de su
sintaxis de C y C++, pero tiene un modelo de objetos más simple y elimina herramientas de
bajo nivel, que suelen inducir a muchos errores, como la manipulación directa de punteros o
memoria.

Las aplicaciones Java están típicamente compiladas en un bytecode, aunque la compilación

en código máquina nativo también es posible. En el tiempo de ejecución, el bytecode es
normalmente interpretado o compilado a código nativo para la ejecución, aunque la
ejecución directa por hardware del bytecode por un procesador Java también es posible.

La implementación original y de referencia del compilador, la máquina virtual y las

bibliotecas de clases de Java fueron desarrollados por Sun Microsystems en 1995. Desde
entonces, Sun ha controlado las especificaciones, el desarrollo y evolución del lenguaje a
través del Java Community Process, si bien otros han desarrollado también
implementaciones alternativas de estas tecnologías de Sun, algunas incluso bajo licencias de
software libre.

Entre noviembre de 2006 y mayo de 2007, Sun Microsystems liberó la mayor parte de sus
tecnologías Java bajo la licencia GNU GPL, de acuerdo con las especificaciones del Java
Community Process, de tal forma que prácticamente todo el Java de Sun es ahora software
libre (aunque la biblioteca de clases de Sun que se requiere para ejecutar los programas Java
todavía no es software libre).

A. Historia
La tecnología Java se creó como una herramienta de programación para ser usada en un
proyecto de set-top-box en una pequeña operación denominada the Green Project en Sun
Microsystems en el año 1991. El equipo (Green Team), compuesto por trece personas y
dirigido por James Gosling, trabajó durante 18 meses en Sand Hill Road en Menlo Park en
su desarrollo.

22
El lenguaje se denominó inicialmente Oak (por un roble que había fuera de la oficina de
Gosling), luego pasó a denominarse Green tras descubrir que Oak era ya una marca
comercial registrada para adaptadores de tarjetas gráficas y finalmente se renombró a Java.

El término Java fue acuñado en una cafetería frecuentada por algunos de los miembros del
equipo. Pero no está claro si es un acrónimo o no, aunque algunas fuentes señalan que
podría tratarse de las iniciales de sus creadores: James Gosling, Arthur Van Hoff, y Andy
Bechtolsheim. Otros abogan por el siguiente acrónimo, Just Another Vague Acronym ("sólo
otro acrónimo ambiguo más"). La hipótesis que más fuerza tiene es la que Java debe su
nombre a un tipo de café disponible en la cafetería cercana, de ahí que el icono de java sea
una taza de cafe caliente. Un pequeño signo que da fuerza a esta teoría es que los 4
primeros bytes (el número mágico) de los archivos .class que genera el compilador, son en
hexadecimal, 0xCAFEBABE. Otros simplemente dicen que el nombre fue sacado al parecer
de una lista aleatoria de palabras.

Los objetivos de Gosling eran implementar una máquina virtual y un lenguaje con una
estructura y sintaxis similar a C++. Entre junio y julio de 1994, tras una sesión maratoniana
de tres días entre John Gaga, James Gosling, Joy Naughton, Wayne Rosing y Eric Schmidt,
el equipo reorientó la plataforma hacia la Web. Sintieron que la llegada del navegador web
Mosaic, propiciaría que Internet se convirtiese en un medio interactivo, como el que
pensaban era la televisión por cable. Naughton creó entonces un prototipo de navegador,
WebRunner, que más tarde sería conocido como HotJava.

En 1994, se les hizo una demostración de HotJava y la plataforma Java a los ejecutivos de
Sun. Java 1.0a pudo descargarse por primera vez en 1994, pero hubo que esperar al 23 de
mayo de 1995, durante las conferencias de SunWorld, a que vieran la luz pública Java y
HotJava, el navegador Web. El acontecimiento fue anunciado por John Gage, el Director
Científico de Sun Microsystems. El acto estuvo acompañado por una pequeña sorpresa
adicional, el anuncio por parte de Marc Andreessen, Vicepresidente Ejecutivo de Netscape,
que Java sería soportado en sus navegadores. El 9 de enero del año siguiente, 1996, Sun
fundó el grupo empresarial JavaSoft para que se encargase del desarrollo tecnológico. Dos
semanas más tarde la primera versión de Java fue publicada.

La promesa inicial de Gosling era Write Once, Run Anywhere (Escríbelo una vez, ejecútalo
en cualquier lugar), proporcionando un lenguaje independiente de la plataforma y un
entorno de ejecución (la JVM) ligero y gratuito para las plataformas más populares de
forma que los binarios (bytecode) de las aplicaciones Java pudiesen ejecutarse en cualquier
plataforma.

El entorno de ejecución era relativamente seguro y los principales navegadores web pronto
incorporaron la posibilidad de ejecutar applets Java incrustadas en las páginas web.

Java ha experimentado numerosos cambios desde la versión primigenia, JDK 1.0, así como
un enorme incremento en el número de clases y paquetes que componen la biblioteca
estándar.

23
Desde J2SE 1.4, la evolución del lenguaje ha sido regulada por el JCP (Java Community
Process), que usa Java Specification Requests (JSRs) para proponer y especificar cambios
en la plataforma Java. El lenguaje en sí mismo está especificado en la Java Language
Specification (JLS), o Especificación del Lenguaje Java. Los cambios en los JLS son
gestionados en JSR 901.

JDK 1.0 (23 de enero de 1996) — Primer lanzamiento.

JDK 1.1 (19 de febrero de 1997) — Principales adiciones incluidas:

o Una reestructuración intensiva del modelo de eventos AWT (Abstract Windowing
Toolkit)
o Clases internas (inner classes)
o JavaBeans
o JDBC (Java Database Connectivity), para la integración de bases de datos.
o RMI (Remote Method Invocation)

J2SE 1.2 (8 de diciembre de 1998) — Nombre clave Playground. Esta y las siguientes
versiones fueron recogidas bajo la denominación Java 2 y el nombre "J2SE" (Java 2
Platform, Standard Edition), reemplazó a JDK para distinguir la plataforma base de
J2EE (Java 2 Platform, Enterprise Edition) y J2ME (Java 2 Platform, Micro Edition).
Otras mejoras añadidas incluían:
o La palabra reservada (keyword) strictfp.
o Reflexión en la programación.
o La API gráfica (Swing) fue integrada en las clases básicas.
o La máquina virtual (JVM) de Sun fue equipada con un compilador JIT (Just in
Time) por primera vez.
o Java Plug-in
o Java IDL, una implementación de IDL (Lenguaje de Descripción de Interfaz) para
la interoperabilidad con CORBA.
o Colecciones (Collections).

J2SE 1.3 (8 de mayo de 2000) — Nombre clave Kestrel. Los cambios más notables
fueron:
o La inclusión de la máquina virtual de HotSpot JVM (la JVM de HotSpot fue
lanzada inicialmente en abril de 1999, para la JVM de J2SE 1.2)
o RMI fue cambiado para que se basara en CORBA.
o JavaSound.
o Se incluyó el Java Naming and Directory Interface (JNDI) en el paquete de
bibliotecas principales (anteriormente disponible como una extensión).
o Java Platform Debugger Architecture (JPDA)

J2SE 1.4 (6 de febrero de 2002) — Nombre Clave Merlin. Este fue el primer
lanzamiento de la plataforma Java desarrollado bajo el Proceso de la Comunidad Java
como JSR 59. Los cambios más notables fueron:
o Palabra reservada assert (Especificado en JSR 41)
o Expresiones regulares modeladas al estilo de las expresiones regulares Perl.

24
 o Encadenación de excepciones. Permite a una excepción encapsular la excepción
de bajo nivel original.
o Non-blocking NIO (New Input/Output) (Especificado en JSR 51)
o Logging API (Specified in JSR 47)
o API I/O para la lectura y escritura de imágenes en formatos como JPEG o PNG.
o Parser XML integrado y procesador XSLT (JAXP) (Especificado en JSR 5 y JSR
63)
o Seguridad integrada y extensiones criptográficas (JCE, JSSE, JAAS)
o Java Web Start incluido (El primer lanzamiento ocurrió en marzo de 2001 para
J2SE 1.3) (Especificado en JSR 56)

J2SE 5.0 (30 de septiembre de 2004) — Nombre clave: Tiger. (Originalmente

numerado 1.5, esta notación aún es usada internamente.) Desarrollado bajo JSR 176,
Tiger añadió un número significativo de nuevas características:
o Plantillas (genéricos) — provee conversion de tipos (type safety) en tiempo de
compilación para colecciones y elimina la necesidad de la mayoría de conversion
de tipos (type casting). (Especificado por JSR 14)
o Metadatos — también llamados anotaciones, permite a estructuras del lenguaje
como las clases o los métodos, ser etiquetados con datos adicionales, que puedan
ser procesados posteriormente por utilidades de proceso de metadatos.
(Especificado por JSR 175)
o Autoboxing/unboxing — Conversiones automáticas entre tipos primitivos (como
los int) y clases de envoltura primitivas (como Integer). (Especificado por JSR
201)
o Enumeraciones — la palabra reservada enum crea una typesafe, lista ordenada de
valores (como Dia.LUNES, Dia.MARTES, etc.). Anteriormente, esto solo podía
ser llevado a cabo por constantes enteras o clases construidas manualmente (enum
pattern). (Especificado por JSR 201)
o Varargs (número de argumentos variable) — El último parámetro de un método
puede ser declarado con el nombre del tipo seguido por tres puntos (p.e. void
drawtext(String... lines)). En la llamada al método, puede usarse cualquier número
de parámetros de ese tipo, que serán almacenados en un array para pasarlos al
método.
o Bucle for mejorado — La sintaxis para el bucle for se ha extendido con una
sintaxis especial para iterar sobre cada miembro de un array o sobre cualquier
clase que implemente Iterable, como la clase estándar Collection.

Java SE 6 (11 de diciembre de 2006) — Nombre clave Mustang. Estuvo en desarrollo

bajo la JSR 270. En esta versión, Sun cambió el nombre "J2SE" por Java SE y eliminó
el ".0" del número de versión. Está disponible en http://java.sun.com/javase/6/. Los
cambios más importantes introducidos en esta versión son:
o Incluye un nuevo marco de trabajo y APIs que hacen posible la combinación de
Java con lenguajes dinámicos como PHP, Python, Ruby y JavaScript.
o Incluye el motor Rhino, de Mozilla, una implementación de Javascript en Java.

25
 o Incluye un cliente completo de Servicios Web y soporta las últimas
especificaciones para Servicios Web, como JAX-WS 2.0, JAXB 2.0, STAX y
JAXP.
o Mejoras en la interfaz gráfica y en el rendimiento.

Además de los cambios en el lenguaje, con el paso de los años se han efectuado muchos
más cambios dramáticos en la biblioteca de clases de Java (Java Class Library) que ha
crecido de unos pocos cientos de clases en JDK 1.0 hasta más de tres mil en J2SE 5.0. APIs
completamente nuevas, como Swing y Java2D, han sido introducidas y muchos de los
métodos y clases originales de JDK 1.0 están obsoletos.

En el 2005 se calcula en 4,5 millones el número de desarrolladores y 2.500 millones de

dispositivos habilitados con tecnología Java.

Entre noviembre de 2006 y mayo de 2007, Sun Microsystems liberó la mayor parte de sus
tecnologías Java bajo la Licencia pública general de GNU, de acuerdo con las
especificaciones del Java Community Process, de tal forma que prácticamente todo el Java
de Sun es ahora software libre (aunque la biblioteca de clases de Sun que se requiere para
ejecutar los programas Java todavía no es software libre)

B. Filosofía
El lenguaje Java se creó con cinco objetivos principales:

1. Debería usar la metodología de la programación orientada a objetos.

2. Debería permitir la ejecución de un mismo programa en múltiples sistemas operativos.
3. Debería incluir por defecto soporte para trabajo en red.
4. Debería diseñarse para ejecutar código en sistemas remotos de forma segura.
5. Debería ser fácil de usar y tomar lo mejor de otros lenguajes orientados a objetos,
como C++.

Para conseguir la ejecución de código remoto y el soporte de red, los programadores de

Java a veces recurren a extensiones como CORBA (Common Object Request Broker
Architecture), Internet Communications Engine o OSGi respectivamente.

C. Entornos de Funcionamiento
El diseño de Java, su robustez, el respaldo de la industria y su fácil portabilidad han hecho
de Java uno de los lenguajes con un mayor crecimiento y amplitud de uso en distintos
ámbitos de la industria de la informática.

D. Industria Relacionada
Sun Microsystems, como creador del lenguaje de programación Java y de la plataforma
JDK, mantiene fuertes políticas para mantener una especificación del lenguaje así como de
la máquina virtual a través del JCP. Es debido a este esfuerzo que se mantiene un estándar
de facto.

Son innumerables las compañías que desarrollan aplicaciones para Java y/o están volcadas
con esta tecnología:

26
 La industria de la telefonía móvil está fuertemente influenciada por la tecnología Java.
El entorno de desarrollo NetBeans™ ha tomado un lugar importante entre la
comunidad de desarrolladores Java.
La fundación Apache tiene también una presencia importante en el desarrollo de
bibliotecas y componentes de servidor basados en Java.
IBM, BEA, IONA, Oracle,... son empresas con grandes intereses y productos creados
en y para Java.

E. Java en Código Abierto

Java se ha convertido en un lenguaje con una implantación masiva en todos los entornos
(personales y empresariales). El control que mantiene Sun sobre éste genera reticencias en
la comunidad de empresas con fuertes intereses en Java (IBM, Oracle) y obviamente en la
comunidad de desarrolladores de software libre.

La evolución basada en un comité en el que participen todos los implicados no es suficiente

y la comunidad demandaba desde hace tiempo la liberación de las APIs y bibliotecas
básicas de la JDK.

(Wikimedia Foundation, Inc., 2009).

Java surgió en 1991 cuando un grupo de ingenieros de Sun Microsystems trataron de

diseñar un nuevo lenguaje de programación destinado a electrodomésticos. La reducida
potencia de cálculo y memoria de los electrodomésticos llevó a desarrollar un lenguaje
sencillo capaz de generar código de tamaño muy reducido.

Debido a la existencia de distintos tipos de CPUs y a los continuos cambios, era importante
conseguir una herramienta independiente del tipo de CPU utilizada. Desarrollaron un
código "neutro" que no dependía del tipo de electrodoméstico, el cual se ejecutaba sobre
una "máquina hipotética o virtual" denominada Java Virtual Machine (JVM). Era la JVM
quien interpretaba el código neutro convirtiéndolo a código particular de la CPU utilizada.
Esto permitía lo que luego se ha convertido en el principal lema del lenguaje: "Write Once,
Run Everywhere". A pesar de los esfuerzos realizados por sus creadores, ninguna empresa
de electrodomésticos se interesó por el nuevo lenguaje.

Como lenguaje de programación para computadores, Java se introdujo a finales de 1995. La

clave fue la incorporación de un intérprete Java en la versión 2.0 del programa Netscape
Navigator, produciendo una verdadera revolución en Internet. Java 1.1 apareció a principios
de 1997, mejorando sustancialmente la primera versión del lenguaje. Java 1.2, más tarde
rebautizado como Java 2, nació a finales de 1998.

Al programar en Java no se parte de cero. Cualquier aplicación que se desarrolle "cuelga" (o

se apoya, según como se quiera ver) en un gran número de clases preexistentes. Algunas de
ellas las ha podido hacer el propio usuario, otras pueden ser comerciales, pero siempre hay
un número muy importante de clases que forman parte del propio lenguaje (el API o
Application Programming Interface de Java). Java incorpora en el propio lenguaje muchos
aspectos que en cualquier otro lenguaje son extensiones propiedad de empresas de software

27
 o fabricantes de ordenadores (threads, ejecución remota, componentes, seguridad, acceso a
bases de datos, etc.). Por eso muchos expertos opinan que Java es el lenguaje ideal para
aprender la informática moderna, porque incorpora todos estos conceptos de un modo
estándar, mucho más sencillo y claro que con las citadas extensiones de otros lenguajes.
Esto es consecuencia de haber sido diseñado más recientemente y por un único equipo.

El principal objetivo del lenguaje Java es llegar a ser el "nexo universal" que conecte a los
usuarios con la información, esté ésta situada en el ordenador local, en un servidor de Web,
en una base de datos o en cualquier otro lugar.

Java es un lenguaje muy completo (de hecho se está convirtiendo en un macro-lenguaje:

Java 1.0 tenía 12 packages; Java 1.1 tenía 23 y Java 1.2 tiene 59). En cierta forma casi todo
depende de casi todo. Por ello, conviene aprenderlo de modo iterativo: primero una visión
muy general, que se va refinando en sucesivas iteraciones. Una forma de hacerlo es
empezar con un ejemplo completo en el que ya aparecen algunas de las características más
importantes.

La compañía Sun describe el lenguaje Java como "simple, orientado a objetos, distribuido,
interpretado, robusto, seguro, de arquitectura neutra, portable, de altas prestaciones,
multitarea y dinámico". Además de una serie de halagos por parte de Sun hacia su propia
criatura, el hecho es que todo ello describe bastante bien el lenguaje Java, aunque en
algunas de esas características el lenguaje sea todavía bastante mejorable.
(Monografias.com S.A.)

Java permite hacer cosas excitantes con las páginas Web que antes no eran posibles. De
manera que en este momento la gran interactividad que proporciona Java marca la
diferencia en las páginas Web. Imagina un Web donde puedes jugar a un juego, como el
fútbol, tú y otras personas que están en lugares remotos forman parte de un equipo y otras
más del contrario, verías a los jugadores animados en la pantalla obedeciendo las
instrucciones de las personas que están jugando al juego desde sitios remotos.

Además las puntuaciones quedarían registradas. O un Web con una aplicación en donde el
usuario pueda hacer transacciones y estas se actualicen en tiempo real. O un sitio que
ofrezca pequeñas aplicaciones como hojas de cálculo o calculadoras para uso de los
visitantes. O uno que muestre figuras 3D, tales como moléculas o dinosaurios que pueden
ser rotados con un clic del ratón.

Java también aumenta el contenido multimedia de un sitio, ofreciendo animaciones fluidas,

gráficos mejorados, sonido y vídeo, fuera de lo necesario para enganchar aplicaciones de
ayuda dentro de sus navegadores Web.

2.4.3. Especificación JavaBean

En la industria electrónica como en otras industrias se está acostumbrado a utilizar
componentes para construir placas, tarjetas, etc. En el campo del software la idea es la
misma. Se puede crear un interfaz de usuario en un programa Java en base a componentes:
paneles, botones, etiquetas, caja de listas, barras de desplazamiento, diálogos, menús, etc.

28
 Si se ha utilizado Delphi o Visual Basic, ya estamos familiarizados con la idea de
componente, aunque el lenguaje de programación sea diferente. Existen componentes que
van desde los más simples como un botón hasta otros mucho más complejos como un
calendario, una hoja de cálculo, etc.

Los primeros componentes que tuvieron gran éxito fueron los VBX (Visual Basic
Extension), seguidos a continuación por los componentes OCX (OLE Custom Controls).
Ahora bien, la principal ventaja de los JavaBeans es que son independientes de la
plataforma.

Muchos componentes son visibles cuando se corre la aplicación, pero no tienen por qué
serlo, solamente tienen que ser visibles en el momento de diseño, para que puedan ser
manipulados por el Entorno de Desarrollo de Aplicaciones (IDE).

Podemos crear una aplicación en un IDE seleccionando los componentes visibles e

invisibles en una paleta de herramientas y situarlas sobre un panel o una ventana. Con el
ratón unimos los sucesos (events) que genera un objeto (fuente), con los objetos (listeners)
interesados en responder a las acciones sobre dicho objeto. Por ejemplo, al mover el dedo
en una barra de desplazamiento (fuente de sucesos) con el ratón, se cambia el texto (el
número que indica la posición del dedo) en un control de edición (objeto interesado en los
sucesos generados por la barra de desplazamiento).

1.1.1. Definición

Un JavaBean o bean es un componente hecho en software que se puede reutilizar y que

puede ser manipulado visualmente por una herramienta de programación en lenguaje Java.

Para ello, se define un interfaz para el momento del diseño (design time) que permite a la
herramienta de programación o IDE, interrogar (query) al componente y conocer las
propiedades (properties) que define y los tipos de sucesos (events) que puede generar en
respuesta a diversas acciones.

Aunque los beans individuales pueden variar ampliamente en funcionalidad desde los más
simples a los más complejos, todos ellos comparten las siguientes características:

Introspección: Permite analizar a la herramienta de programación o IDE como trabaja

el bean.
Personalización: El programador puede alterar la apariencia y la conducta del bean.
Eventos: Informa al IDE de los sucesos que puede generar en respuesta a las acciones
del usuario o del sistema, y también los sucesos que puede manejar.
Propiedades: Permite cambiar los valores de las propiedades del bean para
personalizarlo (personalización)
Persistencia: Se puede guardar el estado de los beans que han sido personalizados por
el programador, cambiando los valores de sus propiedades.

En general, un bean es una clase que obedece ciertas reglas:

29
 Un bean tiene que tener un constructor por defecto (sin argumentos)
Un bean tiene que tener persistencia, es decir, implementar el interface Serializable.
Un bean tiene que tener introspección (introspección). Los IDE reconocen ciertas
pautas de diseño, nombres de las funciones miembros o métodos y definiciones de las
clases, que permiten a la herramienta de programación mirar dentro del bean y conocer
sus propiedades y su conducta.

A. Convenciones
Para funcionar como una clase JavaBean, una clase debe obedecer ciertas convenciones
sobre nomenclatura de métodos, construcción, y comportamiento.

Estas convenciones permiten tener herramientas que puedan utilizar, reutilizar, sustituir, y
conectar JavaBeans.

Las convenciones requeridas son:

Debe tener un constructor sin argumentos.

Sus propiedades deben ser accesibles mediante métodos get y set que siguen una
convención de nomenclatura estándar.

B. Estructura
Dentro de un JavaBean podemos distinguir tres partes:

Propiedades: Los atributos que contiene.

Métodos: Se establecen los métodos get y set para acceder y modificar los atributos.
Eventos: Permiten comunicarnos con otros JavaBeans.

C. Propiedades
Una propiedad es un atributo del JavaBean que afecta a su apariencia o a su conducta. Por
ejemplo, un botón puede tener las siguientes propiedades: el tamaño, la posición, el título, el
color de fondo, el color del texto, si está o no habilitado, etc.

Las propiedades de un bean pueden examinarse y modificarse mediante métodos o

funciones miembro, que acceden a dicha propiedad, y pueden ser de dos tipos:

getter method: lee el valor de la propiedad.

setter method: cambia el valor de la propiedad.

Un IDE que cumpla con las especificaciones de los JavaBeans sabe como analizar un bean
y conocer sus propiedades. Además, crea una representación visual para cada uno de los
tipos de propiedades, denominada editor de propiedades, para que el programador pueda
modificarlas fácilmente en el momento del diseño.

Cuando un programador, coge un bean de la paleta de componentes y lo deposita en un

panel, el IDE muestra el bean sobre el panel. Cuando seleccionamos el bean aparece una
hoja de propiedades, que es una lista de las propiedades del bean, con sus editores asociados
para cada una de ellas.

30
 El IDE llama a los métodos o funciones miembro que empiezan por get, para mostrar en los
editores los valores de las propiedades. Si el programador cambia el valor de una propiedad
se llama a un método cuyo nombre empieza por set, para actualizar el valor de dicha
propiedad y que puede o no afectar al aspecto visual del bean en el momento del diseño.

Las especificaciones JavaBeans definen un conjunto de convenciones (design patterns) que

el IDE usa para inferir qué métodos corresponden a propiedades.

public void setNombrePropiedad(TipoPropiedad valor)

public TipoPropiedad getNombrePropiedad()

Cuando el IDE carga un bean, usa el mecanismo denominado reflection para examinar
todos los métodos, fijándose en aquellos que empiezan por set y get. El IDE añade las
propiedades que encuentra a la hoja de propiedades para que el programador personalice el
bean.

(Wikimedia Foundation, Inc., 2009)

2.4.4. Tecnología ActiveX

ActiveX es un modelo de objeto–componente (COM) desarrollado por Microsoft para
Windows. Usando COM, los desarrolladores pueden crear componentes de software que
realizan una función particular o un conjunto de funciones. Una aplicación de software
puede entonces componerse de uno o varios componentes para proporcionar la
funcionalidad que se propone. Muchas aplicaciones de Microsoft Windows – incluyendo
aquellos de Microsoft como Internet Explorer, Microsoft Office, Microsoft Visual Studio,
Windows Media Player, etc. – usan controles ActiveX para construir su conjunto de
características así como encapsulan su funcionalidad como controles ActiveX de modo que
la funcionalidad pueda ser integrada en otras aplicaciones. Internet Explorer también
permite a los controles ActiveX ser integrados dentro de páginas Web.

Los controles ActiveX son pequeños componentes básicos de un programa pueden ser
usados para crear aplicaciones distribuidas que trabajan sobre Internet por navegadores
Web. Como ejemplos se incluyen aplicaciones personalizadas para datos crecientes, visores
de ciertas clases de archivos y mostradores de animaciones.

Los controles ActiveX pueden ser comparados en algún sentido a un applet Java, pues son
diseñados para descargados y ejecutados desde navegadores Web. Sin embargo, hay
algunas diferencias. Los applets Java pueden ejecutarse sobre casi cualquier plataforma,
mientras que los componentes ActiveX sólo son compatibles con el navegador Web Internet
Explorer de Microsoft y el sistema operativo Windows de Microsoft. Los controles ActiveX
también tienen un nivel mucho más alto de control de Windows que los applets Java,
haciéndolos más poderosos y peligrosos. Malware, como virus informáticos y spyware, a
menudo es distribuido como controles ActiveX en páginas Web.

31
 Los controles ActiveX pueden ser escritos en MFC, ATL, C++, C#, Borland Delphi y
Visual Basic. Ejemplos comunes de controles ActiveX son los botones de comando, cajas
de listas, cuadros de diálogo, y aún el navegador Internet Explorer.

2.5. Metodología a Seguir

2.5.1. Análisis de Requerimientos
En esta fase se llevará a cabo un análisis para determinar los requerimientos que se
contemplarán para el desarrollo de la librería de componentes. Estos requerimientos
definirán qué componentes se desarrollarán y cuáles serán sus características y
comportamiento.

2.5.2. Diseño y Modelado de los Componentes

En esta fase se diseñará y modelará cada uno de los componentes de la librería y kas
relaciones que existen entre ellos, en base a los diagramas UML y utilizando como
herramienta CASE al IDE NetBeans™.

2.5.3. Desarrollo e Implementación

En esta fase se desarrollará e implementará cada uno de los componentes de la librería
utilizando el lenguaje Java y el IDE NetBeans™.

2.5.4. Pruebas y Empaquetamiento

En esta fase se realizarán diversas pruebas a la librería de componentes para depurar errores
y optimizarla. Asimismo se preparará los archivos que se distribuirán, como los archivos
JAR, el código fuente, la documentación HTML y el manual de usuario.

2.6. Diseño de Investigación

La presente investigación corresponde a un diseño experimental, ya que al agregar
un componente y medir su eficiencia, se manipulan las variables de estudio.
Además el estudio consiste en crear una librería; lo cual acarrea diseño e
implementación. Para esta investigación, se utilizará el diseño experimental con pre
prueba, post prueba y grupos de control.

Grupo de Control
Preprueba (x) Postprueba(y) Diferencia(z)
Tabla 5. Diseño Experimental.

Donde:

Pre prueba (x): Se le realizará una prueba antes de implementar la librería de

componentes a los IDE basados en el lenguaje JAVA, a los Estudiantes de
Ingeniería de Sistemas e Informática de la Universidad Nacional del Santa y se
anotarán sus resultados, tomando en cuenta los indicadores que se desean medir.

x: Medición de los indicadores en la pre – prueba.

32
 Post prueba (y): Se le realizará una prueba después de implementar la librería de
componentes a los IDE basados en el lenguaje JAVA, a los Estudiantes de
Ingeniería de Sistemas e Informática de la Universidad Nacional del Santa y se
anotarán sus resultados, tomando en cuenta los indicadores que se desean medir.

y: Medición de los indicadores en la post – prueba.

Diferencia (z): Es la diferencia de las mediciones de indicadores antes y después de

las pruebas.

z = y – x: Resultados obtenidos de las mediciones

2.7. Cobertura del Estudio

2.7.1. Población
Los alumnos de la Escuela Académico Profesional de Ingeniería de Sistemas e Informática
de la Universidad Nacional del Santa.

2.7.2. Muestra
Los alumnos de los ciclos VII y IX de la Escuela Académico Profesional de Ingeniería de
Sistemas e Informática de la Universidad Nacional del Santa.

2.8. Técnicas e Instrumentos de Recolección de Datos

Técnicas Instrumentos
Encuesta Hoja de encuesta
Tabla 6. Técnicas e instrumentos de recolección de datos.

Bibliografía y Linkografía
BarcodeLib.com. (s.f.). Barcode for Java. Recuperado el 20 de Junio de 2009, de
http://www.barcodelib.com/java_barcode/main.html

Gilbert, D., & Morgner, T. (s.f.). Welcome to JFreeChart! Recuperado el 20 de Junio de 2009, de
http://www.jfree.org/jfreechart/

Gnostice Information Technologies. (s.f.). Gnostice PDFOne - Java™. Recuperado el 20 de Junio

de 2009, de http://www.gnostice.com/PDFOne_Java.asp

Horstmann, C., & Cornell, G. (2003). Java 2. Características Avanzadas (Cuarta ed., Vol. II).
Madrid, España: Pearson Education.

Jaspersoft. (s.f.). Welcome to the iReport. Recuperado el 20 de Junio de 2009, de

http://jasperforge.org/projects/ireport

jPowered.com. (s.f.). Vertical Bar Graph Component Library - API Java Bean. Recuperado el 20 de
Junio de 2009, de http://www.jpowered.com/java-bean/graph-chart/vertical-bar-graph/

33
Monografias.com S.A. (s.f.). Manual del Java. Recuperado el 24 de Junio de 2009, de
http://www.monografias.com/trabajos42/manual-de-java/manual-de-java2.shtml?monosearch

Qoppa Software. (s.f.). jPDFViewer™ Java PDF Viewer Bean. Recuperado el 20 de Junio de 2009,
de http://www.qoppa.com/jpvindex.html

Wikimedia Foundation, Inc. (16 de Abril de 2009). JavaBean. Recuperado el 24 de Junio de 2009,
de http://es.wikipedia.org/wiki/JavaBeans

Wikimedia Foundation, Inc. (24 de Junio de 2009). Lenguaje de programación Java. Recuperado el
24 de Junio de 2009, de http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_Java

34