Docstoc

jControls PTI

Document Sample
jControls PTI Powered By Docstoc
					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. 1.2. 1.3. 1.4. 1.5. 1.6. Título ................................................................................................................................... 4 Autor ................................................................................................................................... 4 Asesor.................................................................................................................................. 4 Tipo de Investigación .......................................................................................................... 4 Régimen de Investigación ................................................................................................... 4 Duración del Proyecto ......................................................................................................... 4 Fecha de Inicio: ........................................................................................................... 4 Fecha de Término: ....................................................................................................... 4

1.6.1. 1.6.2. 1.7.

Área de Desarrollo del Proyecto ......................................................................................... 4 Localidad ..................................................................................................................... 4 Institución .................................................................................................................... 4

1.7.1. 1.7.2. 1.8. 1.9. 1.10. 1.10.1. 1.10.2. 1.10.3. 1.11. 1.11.1. 1.11.2. 1.11.3. 1.12. 2.

Unidad Académica .............................................................................................................. 4 Cronograma de Actividades a Desarrollar .......................................................................... 4 Recursos .......................................................................................................................... 5 Personal ....................................................................................................................... 5 Bienes y Materiales ..................................................................................................... 5 Servicios ...................................................................................................................... 5 Presupuesto...................................................................................................................... 6 Bienes y Materiales ..................................................................................................... 6 Servicios ...................................................................................................................... 6 Resumen ...................................................................................................................... 6 Financiamiento ................................................................................................................ 6

Plan de Investigación .................................................................................................................. 7 2.1. Problema ............................................................................................................................. 7 Realidad Problemática................................................................................................. 7 Análisis del Problema.................................................................................................. 8 Formulación del Problema .......................................................................................... 9 Antecedentes ............................................................................................................... 9 Justificación............................................................................................................... 10 Limitaciones .............................................................................................................. 11

2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.5. 2.1.6. 2.2.

Objetivos ........................................................................................................................... 11 2

2.2.1. 2.2.2. 2.3. 2.4.

Objetivo General ....................................................................................................... 11 Objetivos Específicos ................................................................................................ 11

Hipótesis ............................................................................................................................ 11 Fundamento Teórico ......................................................................................................... 12 Desarrollo Basado en Componentes.......................................................................... 12 Lenguaje de Programación Java ................................................................................ 22 Especificación JavaBean ........................................................................................... 28 Tecnología ActiveX .................................................................................................. 31

2.4.1. 2.4.2. 2.4.3. 2.4.4. 2.5.

Metodología a Seguir ........................................................................................................ 32 Análisis de Requerimientos ....................................................................................... 32 Diseño y Modelado de los Componentes .................................................................. 32 Desarrollo e Implementación .................................................................................... 32 Pruebas y Empaquetamiento ..................................................................................... 32

2.5.1. 2.5.2. 2.5.3. 2.5.4. 2.6. 2.7.

Diseño de Investigación .................................................................................................... 32 Cobertura del Estudio ........................................................................................................ 33 Población ................................................................................................................... 33 Muestra ...................................................................................................................... 33

2.7.1. 2.7.2. 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.
1.1.

Datos Generales
Título
CREACIÓN DE UNA LIBRERÍA DE NUEVOS COMPONENTES REUTILIZABLES EN JAVA PARA MEJORAR LA CALIDAD DE DESARROLLO DE SOFTWARE

1.2. 1.3. 1.4. 1.5. 1.6.

Autor
BACH: Jonathan MUÑOZ ALEMAN

Asesor
ING. Sixto DÍAZ TELLO

Tipo de Investigación
Aplicada/Tecnológica

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

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 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 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

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. MATERIALES DE ESCRITORIO Memoria Flash USB 1 CD 1/2 Papel Bond 1 Lapiceros 1/2 EQUIPOS Computadora 1 Impresora 1

Unidad Cost. Unit. Costo Total Unidad Docena Ciento Docena Unidad Unidad S/. 0.00 S/. 4.00 S/. 3.50 S/. 3.00 S/. 0.00 S/. 0.00 S/. 0.00 S/. 2.00 S/. 3.50 S/. 1.50 S/. 0.00 S/. 0.00

Tabla 1. Presupuesto de bienes y materiales.

1.11.2. Servicios

SERVICIO Internet Movilidad

Cant. 640 80

Unidad Horas Viajes

Cost. Unit. Cost. Total S/. 1.00 S/. 640.00 S/. 1.00 S/. 80.00

Tabla 2. Presupuesto de servicios.

1.11.3. Resumen

ITEM Bienes y Materiales Materiales de escritorio Equipos Servicios Imprevistos TOTAL

TOTAL S/. 7.00 S/. 7.00 S/. 0.00 S/. 720.00 S/. 72.70 S/. 799.70

Tabla 3. Presupuesto total.

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

6

2.
2.1.

Plan de Investigación
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 VI: Librería de nuevos componentes reutilizables en Java 11 Indicadores Número de componentes desarrollados Número de propiedades de los componente

VD: La calidad de desarrollo de software

Tiempo de desarrollo de software Número de líneas de código escritas. 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 maestrotrabajadores 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. 2. 3. 4. 5. Debería usar la metodología de la programación orientada a objetos. Debería permitir la ejecución de un mismo programa en múltiples sistemas operativos. Debería incluir por defecto soporte para trabajo en red. Debería diseñarse para ejecutar código en sistemas remotos de forma segura. 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


				
DOCUMENT INFO
Shared By:
Stats:
views:886
posted:6/25/2009
language:Spanish
pages:34
Description: Proyecto de Trabajo de Investigación para el desarrollo de una librería de componentes en Java llamada jControls
Jonathan Muñoz Aleman Jonathan Muñoz Aleman http://geekmelomano.iespana.es
About Solo una persona que ha elegido la observación en lugar del conformismo; alguien que persigue la habilidad (especialmente la técnica) y la imaginación, en lugar de la aceptación social de la mayoría. Ah! y que siente pasión y entusiasmo por la (buena) música.