UNIVERSIDAD AUTÓNOMA DE TLAXCALA DEPARTAMENTO DE INGENIERÍA Y TECNOLOGÍA UNIDAD DE ESTUDIOS DE POSGRADO PRUEBA DE COMPONENTES DE SOFTWARE BASADAS EN EL MODELO DE JAVABEANS TESIS QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN INGENIERÍA EN COMPUTACIÓN PRESENTA: PERLA INÉS VELASCO ELIZONDO. DIRIGIDA POR: M.I. JUAN MANUEL FERNÁNDEZ PEÑA. M.C. MA. ELENA HERNÁNDEZ HERNÁNDEZ. APIZACO, TLAX. ABRIL DE 2001.
Dedico cariñosamente este trabajo a: Mis padres, porque con su invaluable apoyo pude iniciar y terminar esta nueva etapa. Mi hermana Lilia. Sodel, que comparte conmigo la emoción de este nuevo momento. Mi maestro y asesor Juan Manuel Fernández Peña.
Índice Resumen... 1 Abstract... 2 Introducción... 3 1. Sofware Basado en Componentes... 6 1.1 El concepto de componente... 6 1.2 El concepto de software basado en componentes... 8 1.3 Objetos y componentes... 9 1.4 Modelos para el desarrollo... 10 1.4.1 COM y DCOM... 10 1.4.2 Corba... 11 1.4.3 JavaBeans........ 12 1.4.3.1 El bean development kit...... 14 2. Revisión Técnica sobre Prueba de Software..... 17 2.1 La prueba de software... 17 2.2 Objetivos de la prueba del software... 19 2.3 Métodos de prueba del software... 20 2.3.1 Pruebas de caja blanca... 20 2.3.2 Pruebas de caja negra... 22 2.4 Niveles de prueba del software... 23 2.5 Prueba de software para objetos... 25 2.5.1 Generalidades del modelo de desarrollo orientado a objetos... 26 2.5.2 Aspectos a considerar en la prueba del software orientado a objetos... 27
2.5.3 Métodos de prueba de software orientado a objetos... 30 2.5.3.1 Pruebas de unidad... 30 2.5.3.2 Pruebas de integración... 32 2.5.3.3 Pruebas de sistema... 34 2.6 Prueba de software basado en componentes... 35 2.6.1 Métodos de prueba de software basado en componentes... 35 2.6.1.1 Pruebas de unidad... 36 2.6.1.2 Pruebas de integración... 36 3. Descripción del Diseño... 38 3.1 Antecedentes... 38 3.2 La prueba de beans... 39 3.3 Aspectos de diseño... 42 3.3.1 Selección de los componentes... 44 3.3.2 La generación de casos de prueba... 46 3.3.3 La ejecución de casos de prueba... 50 3.3.4 La presentación de resultados... 52 4. Descripción de la Arquitectura e Implementación... 56 4.1 Arquitectura y colaboración entre clases... 56 4.1.1 La invocación de los servicios... 59 4.1.2 La extracción de archivos jar... 61 4.1.3 La generación de casos de prueba... 64 4.1.4 La ejecución de casos de prueba generados automáticamente... 67 4.1.5 La ejecución de casos de prueba generados manualmente... 70 4.1.6 La presentación de resultados... 73
5. Pruebas de Funcionamiento... 77 5.1 Los componentes utilizados... 77 5.2 El componente Puzzle... 78 5.2.1 Los resultados observados... 80 5.3 El componente TextEditor... 82 5.3.1 Los resultados observados... 84 5.4 El componente ProgressBar... 86 5.4.1 Los resultados observados... 87 Conclusiones... 89 Anexo A... 91 Anexo B... 93 Anexo C... 106 Referencias bibliográficas... 109
Resumen. El desarrollo de software basado en componentes hace necesario contar con herramientas adecuadas; entre ellas se encuentran las herramientas de prueba. Los JavaBeans representan una forma de construir aplicaciones a partir de componentes preexistentes. Por el momento solo hay ayuda para probar aspectos gráficos de sus interfaces de usuario, pero no del funcionamiento interno de los beans. Este trabajo presenta una herramienta de prueba de componentes de software construidas bajo el modelo de JavaBeans. El objetivo de la herramienta es proveer al usuario de directrices que le permitan realizar las tareas de selección y evaluación de las componentes mediante la generación y ejecución automática de casos de prueba. 1
Abstract. Component-based software development makes necessary to have adequate tools; some of them are testing tools. JavaBeans are a way to build applications based in preexistent components. At present testing of interfaces graphical aspects is available, but testing beans internal behavior is not. This work presents a testing tool for software components using the JavaBeans model. Testing tool s objective is to offer guides to users on components selection and evaluation through automatic execution and generation of test cases. 2
Introducción. Actualmente el reuso de elementos preexistentes es una práctica común en la actividad de desarrollo de software. Situaciones como la competencia en el mercado para generar nuevos productos o actualizar versiones, han propiciado que muchos desarrolladores busquen nuevas opciones para generar software en tiempos muy cortos. Incluso, en ambientes de desarrollo no comercial, la actividad del reuso también se lleva a cabo; un simple ejemplo es la inclusión de bibliotecas o clases en los programas de un estudiante, con el fin de reutilizar funciones o métodos ya implementados. La creación de nuevas metodologías de desarrollo, cuyas características han permitido alcanzar en diversos grados la rápida construcción de programas, han considerado al reuso como una actividad básica, contribuyendo así a que esta se convierta en una alternativa atractiva en la construcción de software. El desarrollo orientado a objetos y el desarrollo basado en componentes, son ejemplos significativos de lo planteado anteriormente. A pesar de la aceptación alcanzada por estos enfoques, una de las más importantes limitaciones que surgen, es la falta de garantías que se tienen de que el o los elementos de software que se están reusando funcionen correctamente en todas las ocasiones, situación que influye considerablemente en la calidad de los productos que se desarrollan. Java Beans, actualmente es uno de los modelos de desarrollo basados en componentes con gran aceptación, factores como la independencia del sistema operativo, con lo que se pretende eliminar los problemas de plataforma y software, interoperabilidad y capacidad de trabajar en ambientes distribuidos, contribuyen a que el número de personas que utilizan este modelo este creciendo notablemente. A pesar de esto, el área de pruebas es poco robusta. Definitivamente, la prueba de software es una actividad que de una u otra manera es llevada a cabo en algún momento al menos por su desarrollador original. Para ello este puede planear y realizar un proceso de prueba enfocado a un ambiente en el que espera operará su producto. Aunque esto es aceptable, puede no ser suficiente. Muchas veces el ambiente de operación pensado por el desarrollador puede diferir del ambiente que se presenta para la 3
persona que utiliza finalmente dicho elemento de software, por lo que en la prueba desarrollada se pueden haber ignorado algunas situaciones. Así mismo, cuando una persona distinta al desarrollador desea probar un elemento que está reusando, el hecho de ser un elemento reutilizable, de los que generalmente no se tiene mucha información, dificulta esta actividad. En el caso de los componentes, que normalmente se ofrecen como productos terminados, no se dispone del código fuente, por lo que es difícil inspeccionar completamente su estructura interna. Este, además de otros factores propios del modelo de desarrollo impiden que un proceso de prueba pueda llevarse a cabo fácil y eficientemente. Actualmente son pocas las herramientas que permiten evaluar elementos preexistentes. Cuando alguien requiere integrar un elemento de software para construir una aplicación o simplemente para utilizarla de forma aislada, la evaluación que se realiza radica en la mayoría de los casos en una prueba manual, que en el peor de los casos no es nada sistematizada ni fundamentada. Si el usuario requiriera realizar una prueba más exhaustiva, esta prueba seria más amplia y formal, pero en raras ocasiones automatizada, por lo que para llevarla acabo se requiere una cantidad de tiempo considerable. Tomado como temas centrales el desarrollo basado en componentes y la prueba de software, el propósito de este trabajo es presentar una alternativa para la prueba de componentes. Esto se llevará a cabo mediante la implementación de una herramienta que permita realizar pruebas a componentes desarrollados bajo el modelo propuesto por Sun Microsystems, Java Beans. Haciendo uso de las funcionalidades que ofrecerá esta herramienta, se podrán realizar de forma automática la generación y ejecución de casos de prueba, de modo que con los resultados obtenidos en esta última actividad, el usuario de los componentes pueda tener algunas directrices que le permitan realizar con mayor facilidad las tareas de selección y evaluación de las mismas. 4
El tipo de prueba que realizará la herramienta es a nivel de unidad, utilizándose para ello técnicas de prueba funcional. Así mismo, los servicios que ofrecerá la herramienta estarán orientados a los usuarios de los componentes, más que a los desarrolladores originales. Con el propósito de describir el trabajo que se realizará para la creación de la herramienta, este trabajo se organiza fundamentalmente en dos partes, en la primera que comprende los capítulos 1 y 2, se presenta de acuerdo a una revisión bibliográfica los temas Software Basado en Componentes y Métodos de Prueba de software respectivamente, en los cuales se pretende proporcionar al lector un marco teórico de referencia con respecto al diseño de aplicación a desarrollar. La segunda parte que comprende de los capítulos 3 al 5, se concentra en la descripción de la herramienta implementada. Para ello en el capítulo 3 Descripción del Diseño, como su nombre lo indica, se presentarán las consideraciones con respecto al diseño de la herramienta de prueba. En el capitulo 4 Descripción de la Arquitectura e Implementación, se describen detalles referente a la implementación. En el quinto y último capitulo Pruebas de Funcionamiento, se presentan algunas de las pruebas realizadas con el propósito de verificar el adecuado funcionamiento de la aplicación. Al final de este documento, se encuentran secciones que contienen las conclusiones, obtenidas como producto de este trabajo, una sección en donde se citan las referencias bibliográficas, y anexos. El Anexo A que contiene información referente a los valores establecidos para la generación de casos de prueba. El anexo B contiene el manual del usuario de la herramienta. El anexo C presenta detalles de la notación utilizada para la descripción del diseño. 5
Capítulo 1 Software Basado en Componentes. Como respuesta a la necesidad de buscar alternativas que permitan hacer más fáciles las tareas de desarrollo e integración de software, uno de los más recientes modelos de desarrollo es el de componentes. Aspectos como el reuso y la interoperabilidad, muy importantes en la actualidad, son característicos de este enfoque. Puede visualizarse como un modelo de desarrollo bastante prometedor. Con el propósito de ofrecer información que permita al lector conocer sobre el desarrollo a partir de componentes, en este capítulo se presenta una descripción del modelo con base en sus principales características. Así mismo, al término de esta descripción, se presentarán tres modelos muy populares que actualmente se ofrecen en el mercado para construir software bajo esta modalidad: COM+/DCOM, CORBA, y Java Beans. 1.1 El concepto de componente. La palabra componente nos hace pensar en una unidad o elemento con propósito bien definido que, trabajando en conjunto con otras, puede ofrecer alguna funcionalidad compleja. Transportando este concepto al contexto de ingeniería de software, específicamente de desarrollo basado en componentes, un componente es la pieza elemental de este enfoque de desarrollo, de esta forma, a partir de componentes existentes pueden llegarse a construir aplicaciones completas. En términos formales, y de acuerdo con [MAR96], un componente es una pieza de software que cumple con dos características: no depende de la aplicación que la utiliza y, se puede emplear en diversas aplicaciones. Según se cita [SZY97], los asistentes a la ECOOP96 definen a un componente como una unidad de composición con interfaces definidas contractualmente y dependencias 6
contextuales explícitas solamente. Un componente de software puede desplegarse independientemente y estar sujeta a composición por terceros. El análisis de las ideas presentadas en estas definiciones y, de acuerdo con lo que plantea [FER99], se pueden identificar características en común: - Orientación al reuso, lo que nos hace pensar en algo que se puede tomar y utilizar más de una vez. - Interoperabilidad, el componente no puede solo usarse de forma aislada, sino que puede integrarse a otras y trabajar conjuntamente. - Función significativa, el componente tiene una función bien definida, identificable y diferenciable. - Encapsulamiento, generalmente los componentes ocultan detalles acerca de su implementación. Una definición más orientada a un enfoque de desarrollo, es la presentada en [DSO99] en la que un componente se define como un paquete coherente de una implementación de software que puede ser independientemente desarrollado y entregado, tiene interfaces explícitas y bien especificadas para informar los servicios que provee y espera de otros, puede estar constituido por otros componentes, quizás mediante la especialización de algunas de sus propiedades, sin que esto signifique modificar los componentes mismos. Tomando esta última definición se pueden enriquecer algunas de las características presentadas antes considerando también: - Una lista de interfaces proveídas y requeridas, las cuales representan mecanismos indispensables para la interoperabilidad de los componentes. 7
- Una especificación externa, medio que permite principalmente identificar la función del componente. - El código de validación, necesario para verificar, cuando se utilizan mas de un componente, si se conectaron correctamente. - El código ejecutable del componente. 1.2 El concepto de software basado en componentes. El concepto de software basado en componentes considera a todas aquellas aplicaciones que se construyen haciendo uso de componentes de software. En la definición presentada para este concepto por [DSO99], se habla de un enfoque de desarrollo de software en el cual todos los artefactos -desde código ejecutable para la especificación de la interfaz, arquitecturas, modelos de negocios, escalar aplicaciones completas y descomposición de sistemas en partes- pueden ser construidos por ensamble, adaptación y conexión de componentes existentes dentro de una variedad de configuraciones. Es claro que las características descritas para este enfoque de desarrollo suenan bastante atractivas; de hecho muchos autores resaltan algunas otras como el reuso de implementaciones e interfaces, la facilidad de mantenimiento y actualización de aplicaciones o la posibilidad de desarrollo en paralelo de diferentes partes de un sistema. Ante este panorama, es importante hacer mención de que al ser esta un área de investigación relativamente joven, existen muchos aspectos que aún no son lo suficientemente robustos. Carencias como el soporte disponible, la selección de componentes, el manejo de excepciones o bien la prueba de integración de componentes son situaciones que se destacan en [FER99]. 8
1.3 Objetos y componentes. Existen algunos aspectos comunes entre los objetos y los componentes que pueden hacer que estos se entiendan como conceptos equivalentes. Aunque hay similitudes, existen marcadas diferencias que permiten entenderlos como entidades diferentes, aunque no por ello excluyentes una de otra. Según [DSO99] los componentes son artefactos de software que representan el trabajo realizado por los desarrolladores. Por otra parte, un objeto se concibe como una instancia identificable creada en el sistema en ejecución, el cual es parte de un componente. Esta idea permite comprender que un componente puede contener uno o más objetos. En términos reales, un componente se manifiesta frecuentemente como una colección de objetos. Finalmente, con el propósito de diferenciar a los componentes de los objetos, a continuación se presentan algunas características que se destacan en [FER99] y [DSO99]: - Los componentes tienen persistencia, los objetos solo utilizan memoria. - Los componentes utilizan otras formas de comunicación como eventos, en lugar de limitarse al uso de mensajes como los objetos. - La granularidad de los componentes es mayor que la de los objetos, un componente puede presentarse como varios objetos de diferentes clases. - El paquete que contiene a el componente, incluye la especificación de las interfaces proveídas y requeridas, mientras que la en los objetos estas especificaciones se concentran en las operaciones proveídas. 9
1.4 Modelos para el desarrollo. La metodología de desarrollo basada en componentes, ha adquirido el respaldo de compañías importantes como Microsoft y Sun que han propuesto sus propios modelos de desarrollo. En las siguientes secciones se describen tres de los más populares actualmente, COM+/DCOM, CORBA y Java Beans. 1.4.1 COM y DCOM. El Component Object Model (COM), es la propuesta de Microsoft en materia de componentes, [MIC00]. Aunque inicialmente fue creado para resolver problemas en la construcción de documentos con OLE para Windows 3.1, este modelo ha sido enriquecido con el propósito de permitir la construcción de aplicaciones a partir de componentes. COM es esencialmente un esquema de integración, de modo que los componentes que se construyen para trabajar bajo este modelo, deben describir su comportamiento bajo las consideraciones de este esquema, el cual es popularmente conocido como estándar binario. Este estándar permite que las interfaces de los componentes se presenten a los clientes como un conjunto de apuntadores a tablas en memoria, llamadas tablas virtuales de funciones o vtables. El llamado de funciones entre componentes se realiza utilizando estos apuntadores, ocultándose así detalles de implementación, lo cual permite que componentes que estén escritos en diferentes lenguajes de programación de los que se pueden incluir a C++, Small Talk, Ada, VisualBasic, Delphi o Power Builder, puedan comunicarse. Dadas las características de las vtables, las interfaces no pueden definirse utilizando herencia múltiple, porque se deben considerar la posibilidad de tener varias vtables y más de un apuntador por interface. Las interfaces COM se definen utilizando un lenguaje especial denominado IDL. La compilación de estas interfaces, produce una especie de librerías que contienen información sobre los metadescriptores del objeto, de sus interfaces, de las estructuras definidas por el 10
usuario y de los elementos referidos por el componente, así como un mapa de memoria para las operaciones públicas. Distributed COM, mejor conocido como DCOM, es una extensión de COM que se implementa como una respuesta a la necesidad de aplicaciones distribuidas, proporcionando capacidades para el trabajo con componentes que residen en diferentes computadoras. DCOM utiliza como mecanismo de comunicación los llamados a procedimientos remotos (RPC), los cuales son transparentes para el cliente. Tanto COM como DCOM son modelos que inicialmente fueron implementados para trabajar bajo ambientes Windows y Windows NT, sin embargo actualmente existen versiones para operar con MacOS y UNIX. Como se mencionó inicialmente el funcionamiento de COM y DCOM, se basa estrictamente en el estándar binario, por lo que los componentes construidos para estos modelos no son del todo independientes de la plataforma, en caso de migrar a otros entornos, para poder utilizare los componentes necesitan ser recompilados para la plataforma en que se van a utilizar o bien, disponer el interprete del formato binario correspondiente. 1.4.2 CORBA. CORBA, Common Object Request Broker Architecture, es una infraestructura abierta para el manejo de objetos distribuidos que esta siendo estandarizada por el Object Management Group (OMG), [ORG00]. En CORBA, un objeto se considera como una instancia de una clase que encapsula operaciones, atributos y excepciones. CORBA permite que los objetos puedan comunicarse con otros sin necesidad de preocuparse por donde están localizados o por quien han sido diseñados. Para esto, se han considerado algunos elementos importantes como: un lenguaje de definición de interface (IDL) y una API que provee al programador la interacción cliente-servidor entre componentes con la implementación especifica de un Object Request Broker (ORB), el cual es una especie de infraestructura en CORBA que permite que los objetos puedan comunicarse. 11
Un componente expone un conjunto de interfaces, implementadas utilizando un lenguaje de definición llamado OMG Interface Definition Language (OMG IDL), mismas que definen las operaciones de los objetos. Actualmente existen estándares para el mapeo de un IDL a lenguajes de programación como C, C++, Java, Smalltalk, o Ada. Una vez que la interfaz se ha definido, se procede a generar dos archivos especiales, un archivo denominado stub para el cliente y, un archivo skeleton para el servidor, estos archivos son una especie de pegamento entre el cliente y el servidor con el ORB que le permiten acceder a sus interfaces. El Object Request Broker (ORB), provee un mecanismo para la comunicación transparente entre clientes y objetos, actuando como un intermediario para realizar la comunicación ya sea local o remota entre componentes. El ORB simplifica la programación distribuida desligando del cliente detalles sobre la invocación de los métodos. Para ello, intercepta la solicitud, encuentra el objeto que corresponde a dicha solicitud, invoca al método correspondiente y regresa el resultado. Al delegarse al ORB todas estas responsabilidades, el cliente no tiene que preocuparse por detalles sobre la localización del objeto, sobre el lenguaje de programación en el cual el objeto ha sido implementado, del sistema operativo, u otros aspectos propios del sistema. 1.4.3 JavaBeans. Actualmente uno de los modelos de desarrollo de software basado en componentes con mayor aceptación, es el propuesto por Sun Microsystems [SUN97], conocido como Java Beans. Java Beans es una API implementada para la construcción y uso de componentes escritos en Java, los cuales son comúnmente llamados Beans. Esta API es proporcionada por SUN como una herramienta visual que permite la carga, utilización, modificación, así como también interconexión de Beans, con el propósito de construir nuevos Beans, applets o bien aplicaciones completas. 12
Retomando la idea de [VAN98], una forma útil para describir a un Bean es comparándolo con una especie de caja negra; una unidad de la cual se conoce su funcionalidad pero no su implementación o estructura interna. Siendo un Bean un elemento de software sobre el cual solo se conoce su función, es preciso contar con algún mecanismo que permita la comunicación con él. En este modelo, ese mecanismo de comunicación consiste en una interfaz, a partir de la cual, se puede acceder a los elementos principales de un Bean: sus métodos, propiedades y eventos. En Java Beans, los métodos implementados en un Bean, especialmente los definidos con el prefijo set o get, son un medio para interactuar con el. Los métodos pueden entenderse como servicios con efectos específicos que el usuario puede invocar en algún momento. Las propiedades son conceptualmente equivalentes a lo que en el software tradicional se conocen como atributos, estos consisten en conjunto de características que un usuario puede leer o modificar haciendo uso de los métodos de acceso. Los eventos son utilizados por el Bean como un medio de comunicación con otros Beans. Un evento se presenta como un cambio de estado que el componente puede notificar a su ambiente. El evento lleva información de quién lo genera, así mismo puede llevar datos y aún objetos que migran de una clase a otra. Puesto que existen otros modelos de desarrollo basados en componentes, en Java Beans se han establecido algunas capacidades con el propósito de distinguirlo de otros. La característica más importante, es por supuesto, que el componente este escrito en Java, además de soportar las siguientes capacidades: a) Introspección, mecanismo mediante el cual se pueden descubrir las propiedades, métodos y eventos que un Bean contiene. 13
b) Soporte a propiedades, la posibilidad de conocer las características de los atributos y la capacidad de poder ser modificados a tiempo de diseño. c) Soporte a eventos, actividades como generación, escucha o respuesta a eventos con el propósito de comunicarse con otros Beans. d) Persistencia, capacidad para salvar y recuperar las especializaciones realizadas a un Bean. El modelo propuesto por Sun Microsystems, permite interrelacionar los componentes construidos bajo sus propias consideraciones con componentes de otros lenguajes y modelos, destacando principalmente la compatibilidad con el estándar de CORBA. Aunque los Beans han sido pensados para ser simples procesos locales, recientemente se ha propuesto una alternativa para trabajar con componentes remotos diseñadas para correr en un servidor y ser invocados por clientes, esta propuesta es conocida como Server Beans o Enterprise Java Beans (EJB) [SUN00]. Los EJB cuentan con mecanismos que les permiten ofrecer nuevos y mejores servicios entre los que destacan los de seguridad, manejo de transacciones, concurrencia y persistencia. 1.4.3.1 El Bean Development Kit. El Bean Development Kit (BDK), es un ambiente visual que permite construir y utilizar Beans. Con el propósito de realizar estas tareas, el BDK implementa tres elementos principales: el BeanBox, el ToolBox, y el PropertySheet. La apariencia de estos elementos, después de haberse seleccionado un Bean, se presenta en la Figura 1.1. El BeanBox, que es el lugar donde se visualiza y modelan algunos de los aspectos involucrados con el comportamiento de un Bean, en este espacio el usuario puede conectar Beans y definir como quiere que se realicen las interacciones entre ellos. Para esto, el 14
BeanBox ofrece al usuario un conjunto de menúes, que incluyen acciones como salvar el contenido actual del BeanBox -incluyendo aspectos como tamaño, posición, estado-, generación de applets a partir del contenido del BeanBox, cargar archivos JAR, realizar un reporte de introspección al Bean, listar los métodos que lanzan eventos, etc. Figura 1.1 Apariencia del BDK. En el BeanBox se presenta al usuario una vista, en tiempo de diseño, de lo que ocurriría cuando la aplicación se ejecute fuera de este ambiente de trabajo. Ya se ha mencionado que un componente puede estar conformado por varias clases, las cuales en este modelo deben estar contenidas en un archivo JAR. Un archivo JAR es muy similar a un archivo ZIP, es un archivo que comprime y almacena varios archivos. De hecho, la principal diferencia entre un archivo ZIP y un JAR, es que este último requiere de un archivo especial denominado MANIFEST.MF, que contiene la descripción de lo que contiene el JAR, dicho de otro modo, el archivo MANIFEST.MF almacena los meta datos del archivo JAR. 15
El ToolBox es un contenedor de Beans, el cual utiliza los archivos JAR localizados en un directorio predefinido dentro del ambiente de referencia, beans/jars. Los mecanismos implementados en el ToolBox examinan el contenido de estos archivos, de forma que puedan mostrarse los Beans contenidos en él y así, permitir al usuario seleccionar y posteriormente colocar los Beans dentro del BeanBox para su manipulación. Al iniciarse BeanBox, este carga de forma automática todos los Beans contenidos en los archivos JAR, sin embargo se pueden cargar JAR de forma manual mediante el menú File LoadJar del BeanBox. Ya se ha mencionado que la apariencia de un Bean puede cambiarse mediante la manipulación de sus propiedades, métodos y eventos; el PropertySheet muestra y permite modificar los valores de las propiedades de un Bean. Si se selecciona un Bean en el BeanBox, en el PropertySheet se despliegan los nombres de cada una de las propiedades y de sus valores actuales. Estos valores pueden ser editados por el usuario modificándose así la apariencia y comportamiento del Bean, aspectos que en muchos casos pueden ser apreciables desde el BeanBox. 16
Capítulo 2 Revisión Técnica sobre Prueba de Software. Cuando se desarrolla software, una de las actividades asociadas a este proceso es la prueba; de hecho, se ha establecido formalmente que la prueba es una actividad fundamental dentro de cada una de las etapas del proceso de desarrollo de software. La prueba es indispensable, puesto que a partir de ella se puede determinar la calidad de los productos implementados; a pesar de esto, no es difícil percibir como su importancia se ha subestimado y en ocasiones hasta ignorado. Desde hace ya mucho tiempo, la prueba ha sido un tema muy importante en la ingeniería de software, a partir de cual se han generado un gran número de trabajos. En este capítulo se presenta una revisión técnica sobre la prueba de software, abordándose fundamentalmente los enfoques de prueba propuestos para probar software construido bajo un enfoque funcional, orientado a objetos y basado en componentes. 2.1 La prueba de software. Para muchas de las actividades que lleva a cabo el ser humano, la prueba es una actividad necesaria que permite determinar la calidad de estas. Hoy por ejemplo, se realizan pruebas para determinar resistencia de determinados materiales, para determinar la vida útil de diversas maquinarias y equipos, o bien para verificar que ciertas tareas se realicen de forma correcta. Definitivamente la prueba es una actividad fundamental en muchos procesos de desarrollo, incluyendo el del software. De manera general, se puede decir que la prueba de software permite al desarrollador determinar si el producto generado satisface las especificaciones establecidas. Así mismo, una prueba de software permite detectar la presencia de errores que pudieran generar salidas o comportamientos inapropiados durante su ejecución. 17
De acuerdo a la IEEE [IEEE90] el concepto de prueba (testing) se define como: Una actividad en la cual un sistema o componente es ejecutado bajo condiciones especificas, se observan o almacenan los resultados y se realiza una evaluación de algún aspecto del sistema o componente. Cuando se habla de condiciones especificas en la definición anterior, se puede suponer la presencia de una especie de ambiente de operación de la prueba, para el cual deben existir determinados valores para las entradas y las salidas, así como también ciertas condiciones que delimitan a dicho ambiente de operación. Formalmente esto es conocido como caso de prueba. La IEEE [IEEE90] define un caso de prueba como: Un conjunto de entradas, condiciones de ejecución y resultados esperados diseñados para un objetivo particular. A partir de las definiciones anteriores y retomando las ideas presentadas en [WOH98] y [FER99], en un proceso de prueba de software, se pueden identificar las siguientes acciones: a) preparar una serie de casos de prueba, b) llevar a cabo dichos casos de prueba, c) decidir cuando suspender la prueba. d) evaluar los resultados generados por la prueba, e) emitir un criterio de evaluación. De lo anteriormente presentado surgen cuestionamientos como: cómo seleccionar casos de prueba representativos?, cuántas pruebas realizar? o bien cómo decidir si es o no de calidad el producto evaluado?, los cuales permiten entender que cada una de estas acciones 18
requiere especial atención. Por fortuna, actualmente existe una base teórica que permite guiar la puesta en marcha de estas actividades. Términos como falla, equivocación y error, pueden considerarse como sinónimos, sin embargo, dentro del contexto de prueba de software no es prudente realizar esta suposición. Con el propósito evitar confusiones y presentar al lector conceptos básicos en materia de pruebas, se presentan estas definiciones tomadas de [IEEE90] : a) Equivocación (mistake): Acción del ser humano que produce un resultado incorrecto. b) Defecto o falta (fault): Un paso, proceso o definición de dato incorrecto en un programa de computadora. El resultado de una equivocación. c) Falla (failure): Resultado incorrecto. El resultado de una falla. d) Error (error): Magnitud por la que el resultado es incorrecto. 2.2 Objetivos de la prueba de software. Un buen preámbulo, antes de establecer los objetivos de la prueba de software es recordar la afirmación realizada por Dijkstra en los años 70 y citada en [PRE98], en donde se plantea que el hecho de realizar una prueba no garantiza la ausencia de defectos, sino solamente se demuestra la existencia de éstos. 19
Como ya se mencionó en la sección anterior, la prueba de software se realiza con el propósito de encontrar algo que difiera a las especificaciones planteadas para el producto o bien, para detectar la presencia de situaciones que pudieran generar resultados inapropiados. Aunque a grandes rasgos estas razones pueden orientar el sentido de una prueba, en [MYE79] se presentan algunas normas que pueden servir como objetivos: a) La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. b) Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces. c) Una prueba tiene éxito si se descubre un error. 2.3 Métodos de prueba de software. Desde hace ya algunos años, han surgido y evolucionado una variedad de métodos para realizar pruebas de software. Las alternativas más significativas en este contexto son las pruebas de caja blanca y las pruebas de caja negra; las primeras, pruebas orientadas a la estructura y las segundas al comportamiento del software. A continuación se hace una descripción de algunas de las propuestas que plantean cada una de estas alternativas, tomando material de las referencias [JOR95], [PRE98] y [KIT96]. 2.3.1 Pruebas de caja blanca. La pruebas de caja blanca enfocan su atención a los detalles procedimentales del software, por ello la implementación de estas pruebas depende fuertemente de la disponibilidad de código fuente. Este tipo de pruebas, permiten generar casos para ejercitar y 20
validar los caminos de cada módulo, las condiciones lógicas, los bucles y sus límites, así como también para las estructuras de datos. Las pruebas de caja blanca también son conocidas como pruebas de caja de cristal o pruebas estructurales. Algunas de las pruebas más significativas dentro de este enfoque son: - Prueba de caminos. En este tipo de prueba se realiza un análisis sobre una representación gráfica de un programa denominada grafo de control. En este grafo, los nodos representan bloques de instrucciones de un programa y los flujos de ejecución para dichas instrucciones se representan por medio de aristas. A partir de este grafo, se puede identificar un conjunto básico de caminos de ejecución, sobre el cual se pueden realizar pruebas con el propósito de ejercitar el flujo de ejecución de los caminos en una unidad. - Prueba de condiciones. Basándose de igual forma en un grafo de control, pueden generarse casos de prueba para elementos individuales de expresiones lógicas. De esta forma se pretende probar cada condición con todas sus posibles alternativas. - Prueba de ciclos. A partir del grafo de control, pueden generarse casos de prueba para las iteraciones definidas en los programas con el propósito de verificar si se realizan de forma correcta. - Prueba de definición de datos. Estas pruebas son realizadas con el objetivo de encontrar posibles contradicciones o redundancias en la definición de los datos utilizados en el software. Para ello se realiza un análisis del comportamiento de cada uno de los datos o cada una de los flujos de ejecución. 21
2.3.2 Pruebas de caja negra. Este tipo de pruebas, conocidas también como pruebas funcionales o pruebas de comportamiento, concentran la atención en generar casos de prueba que permitan ejercitar los requisitos funcionales de un programa. A diferencia de las pruebas de caja blanca, que se basan en la lógica interna del software, este tipo de pruebas se concentran en su funcionalidad, por lo que mucho del trabajo se realiza interactuando con la interfaz del software. Los casos de prueba generados en este enfoque, se diseñan a partir de valores entrada y salida. De esta forma, se puede determinar la validez de una salida para un conjunto de entradas proporcionadas. La aplicación de pruebas de caja negra permiten detectar errores como funciones incorrectas o ausentes, errores en estructuras de datos, errores de rendimiento, así como errores de inicialización y terminación. Estas son algunas de las pruebas más conocidas en este contexto: - Partición equivalente. La idea de esta técnica, es en dividir los valores válidos y no válidos para entradas y salidas en un número reducido de particiones de forma que, el comportamiento del software sea el mismo para cualquier valor contenido en una partición particular. El propósito principal de una partición es reducir la cantidad de casos de prueba generados en el proceso. - Análisis de los valores límite. La generación de casos de prueba en esta técnica, se enfoca en los valores limites, esto bajo la consideración de que existe una tendencia a fallar precisamente cuando el software trabaja con valores extremos de la variable de entrada. Generalmente los valores establecidos para generar los casos de prueba son el mínimo, valores un poco arriba del mínimo, valor máximo y valores un poco arriba del máximo. 22
- Pruebas según la experiencia (error guessing). Este tipo de prueba la generación de casos se realiza a partir de la intuición y la experiencia. La idea básica es redactar una lista de las posibles fallas o de las posibles situaciones en las cuales suele ocurrir algún problema y así desarrollar casos de prueba basados en la información contenida en estas listas. - Tablas de decisión. Este tipo de prueba permite describir el comportamiento de un programa a partir de un conjunto de acciones que este realiza cuando se opera bajo determinadas condiciones. En este enfoque, las condiciones pueden ser interpretadas como entradas de un programa y las acciones como las salidas producidas. Para ello se pueden utilizar conectores lógicos y (and), o (or) y no (not). Al involucrar aspectos de lógica, se dice que este tipo de prueba se hace más rigurosa, que permite además transformar una especificación en lenguaje natural en una especificación más formal. 2.4 Niveles de prueba del software. Un nivel de prueba permite especificar el alcance de la prueba de software que se realiza, se pueden identificar principalmente dos niveles: a) Bajo nivel. En este nivel están consideradas todas aquellas pruebas que se realizan a componentes individuales de un programa. Las pruebas que se pueden realizar en este nivel son: Pruebas de unidad. Como su nombre lo indica, este tipo de prueba se aplica a elementos de software individualmente, excluyendo todos aquellos casos en los que se considere la interacción con otras unidades. El propósito fundamental de una prueba de unidad es 23
descubrir diferencias entre la especificación del modulo de la interfaz y el comportamiento efectivo. Pruebas de integración Las pruebas de integración se realizan con el propósito de ejercitar la arquitectura de un sistema. Una vez que ya se han probado que las unidades funcionan de forma correcta de forma aislada, se procede a probar cómo funcionan al integrarlas con otras de forma que se llegue a probar el comportamiento de un sistema final. La forma en que se pude organizar la integración de las unidades para la prueba puede realizarse siguiendo enfoques como el ascendente, descendente, big bang, o sandwich. b) Alto nivel. En éste nivel las pruebas se orientan a un producto completo; para ello se proponen las siguientes alternativas: Pruebas de sistema Este tipo de pruebas permiten probar el sistema como un todo así como también aspectos relacionados con la integración del producto a otros sistemas. Pruebas de usabilidad. El diseño de pruebas de usabilidad, requiere considerar a los usuarios que trabajan con el producto, con el propósito de observar sus respuestas hacia éste. De ésta forma se pueden observar discrepancias existentes entre las interfaces implementadas y los requerimientos de los estilos de trabajo de los usuarios finales. Pruebas de función. Este tipo de pruebas tiene como objetivo detectar inconsistencias entre la especificación funcional de un programa y su comportamiento actual. 24
Pruebas de aceptación. Realizando estas pruebas se puede comparar el producto final con las necesidades finales de los los usuarios. Pruebas de regresión. Las pruebas de regresión son recomendables cuando partes del software se modifican, ya que permiten verificar que los cambios realizados no generan comportamientos no deseados. 2.5 Prueba de software para objetos. Como consecuencia de las facilidades y beneficios que ofrece, actualmente una de las nuevas alternativas para desarrollo de software con mayor aceptación es la metodología orientada a objetos. Si bien es cierto que este nuevo enfoque ha sido adoptado por muchos, es también cierto que estas personas han tenido que enfrentarse y adaptarse a cambios bastante significativos. Conceptos como objeto, herencia y encapsulación marcan una nueva perspectiva que contrasta con los modelos de desarrollo anteriormente utilizados. Esta nueva percepción ha impedido que áreas de vital importancia, como la prueba de software, no hayan alcanzado el desarrollo y la robustez que requieren. Es importante destacar que mucho del software que se está fabricando hoy es orientado a objetos, por lo resulta evidente la necesidad de contar con herramientas o al menos guías de acción para realizar esta actividad. Esta falta de trabajos quizá sea debida a la suposición y afirmación inicial de algunos autores de que el software orientado a objetos, al tener como una característica esencial el reuso, está propenso a presentar menos errores que el software construido usando las metodologías tradicionales. Lamentablemente las experiencias obtenidas han demostrado que no es así. 25
2.5.1 Generalidades del modelo de desarrollo orientado a objetos. En cierto grado algunos de los conceptos de la orientación a objetos han estado presentes en los lenguajes de programación que se han utilizado; sin embargo la programación orientada a objetos aparece formalmente durante la década de los 80, como una alternativa de desarrollo de software que ofrece características muy atractivas: mejor modularidad en los programas, mayor flexibilidad y una de las más significativas el reuso, característica nada despreciable en ambientes de trabajo donde se requiere construir software en tiempos muy cortos. De acuerdo con [PER90], la programación orientada a objetos puede definirse como la descripción de tareas en términos de los objetos que la misma tarea envuelve, así como de las propiedades de dichos objetos. A pesar de lo simple de la definición, se puede apreciar que un elemento muy representativo en este modelo es el objeto. Profundizando sobre este tema, es posible decir que la programación orientada a objetos gira en torno a dos conceptos: el objeto y la clase. En los lenguajes de programación imperativos, los elementos más significativos son las estructuras de datos y los procedimientos, los cuales aparecen en forma desligada. En el modelo orientado a objetos, existe una unidad que conjunta estos elementos, esta unidad es el objeto. La definición formal de un objeto esta contenida en una clase a la que pertenece. Esta definición contiene las características del objeto, las cuales se modelan en términos los atributos, datos que el objeto utiliza, y los métodos que son las funciones que manipulan a estos datos. A continuación se presentan descripciones mas amplias de clase y objeto, que permitirán tener una mejor comprensión de lo mencionado anteriormente: 26
Según [KIR94], un objeto tiene un estado y un comportamiento. El estado del objeto lo determina un conjunto de atributos. El comportamiento de un objeto está definido por el conjunto de métodos del objeto. Una clase describe el comportamiento común de un grupo único de objetos. Describe todos los métodos y los atributos de esos objetos. Los objetos son creados mediante la instanciación de clases. Para [PER90], un objeto es un entidad instanciada la cual tiene: 1. un conjunto de operaciones a las cuales responde, 2. un estado el cual es afectado por un subconjunto de operaciones, 3. la habilidad de enviar mensajes a otros objetos para invocar operaciones. Una clase especifica las propiedades de un objetos y contiene: 1. una interfaz la cual detalla como se accede a las propiedades públicas de la clase, 2. un cuerpo de código que implementa las operaciones definidas en la interfaz, y 3. variables de instancia, las cuales implementan el estado del objeto. Además de clase y objeto, existen otros conceptos relacionados con esta forma de programación; encapsulación, polimorfismo y herencia, son algunos de los más destacables. En la siguiente sección se abordan cada uno de ellos, dentro del contexto de prueba de software. 2.5.2 Aspectos a considerar en la prueba de software orientado a objetos. Al igual que el software construido utilizando otros enfoques de desarrollo, todo producto construido a partir del modelo orientado a objetos requiere ser sometido a pruebas con el propósito de garantizar su calidad. En términos generales, se puede decir que los dos enfoques mas representativos en materia de pruebas, de caja blanca y de caja negra, son aplicables al software orientado a objetos en cierta medida. Sin embargo como se menciona en 27
[FER99], existen algunas características del software orientado a objetos que generan problemas adicionales no cubiertos por las técnicas tradicionales de prueba. Existe una referencia común en [BIN95-A], [PER90] o [FER99], acerca de que la unidad básica para la prueba de software orientado a objetos es la clase. A pesar de ello, cuando se prueba al software orientado a objetos, no es posible realizar una prueba para una clase por sí misma, sino que hay que realizarla para una instancia de ésta, es decir para un objeto. Una característica importante del enfoque orientado a objetos es la encapsulación. Un objeto encapsula su estado y sus funciones asociadas. La abstracción, concepto que define la capacidad de solo destacar las características esenciales de un objeto de tal forma que se puede separar su comportamiento esencial de su implementación, va estrechamente ligada con la encapsulación. Indudablemente la posibilidad de poder encerrar dentro de un contenedor físico o lógico elementos como arreglos, registros o incluso objetos parece ser muy atractiva para ciertas actividades, sin embargo en el contexto de prueba esto no es realmente una ventaja. Como se cita en [BAS99], el ocultar todos los detalles del objeto que no contribuyen a sus características esenciales, por ejemplo su estructura y la implementación de sus métodos, hace que parte de un objeto sea inaccesible para el mundo. Naturalmente, esto obstaculiza la eficiencia de las pruebas, ya que para realizarlas, en algún momento se requiere monitorear el estado de un objeto. Esto es difícil de realizar con características como la encapsulación y la abstracción, pues la dificultad de visualizar el estado interno del objeto impide consultar información que podría requerirse para el desarrollo de la prueba. [BIN95-A]. Por otra parte, la herencia es otra de las características que han venido a facilitar en gran medida el desarrollo de sistemas, la posibilidad de que una clase pueda ser escrita en términos de variaciones de otras clases es una ventaja significativa. Puede pensarse que esto apoya la prevención de fallas al construir software. Desgraciadamente, se ha comprobado que. mediante esta práctica, se tienen muchas posibilidades de cometer errores, porque 28
generalmente los elementos heredados son sometidos a algún tipo de refinamiento o redefinición y en algunos casos eliminación de componentes [FER99]. Cuando un objeto es creado a partir de características heredadas, se genera un nuevo contexto que puede ser diferente al que pudiera crearse por la clase antecesesora si esta trabajara de manera aislada y, por tanto, presentarse problemas ante situaciones no previstas en el nuevo contexto. Todas estas situaciones hacen que autores como [BIN95-A], afirmen que realizar una prueba a los métodos heredados debe ser una regla más que una excepción. La herencia en cierta medida trae como consecuencia reuso, lo que genera una interrogante común con respecto a la formulación de las pruebas: las subclases de una clase que ya ha sido probada deben de ser probadas nuevamente?. Si la respuesta es sí, en referencias como [PER90], se habla de diferentes niveles de herencia lo que incrementa el número de pruebas a realizar. Así mismo, en [BIN95-B] se afirma que el reuso no garantiza que el software esté exento de errores, ya que no es posible determinar si un número suficiente de rutas y estados hayan sido ejercitados. Otro aspecto que determina la dificultad de las pruebas que se realizan al software orientado a objetos es el polimorfismo. En [BIN95-A] se explica que cada vez que se realiza una instancia diferente de un objeto como producto del polimorfismo en los métodos, se requiere una prueba separada. Realizar una prueba separada para cada una de la formas de un método es una tarea difícil, la complejidad y el tiempo requerido crece considerablemente cuando se tienen que definir todos los posibles errores y obstáculos que pueden presentarse. En los sistemas orientados a objetos, el flujo de control se lleva a cabo mediante el paso de mensajes entre objetos. Cuando un mensaje es enviado de un objeto u otro, la consecuencia es, generalmente, que el objeto receptor ejecute alguna operación para examinar o alterar su estado. En [PER90] hace hincapié que el paso de mensajes es un punto fundamental al realizar la prueba. Si bien estos son algunos de los aspectos más significativos y de referencia común en revisiones bibliográficas, de igual forma pueden mencionarse la dependencia de estado, el 29