TEMA 5: OPTIMIZACIN DEL SOFTWARE

Contenido
Introduccin .................................................................................................................................. 4 1. Diseo y realizacin de pruebas de software ........................................................................ 5 1.1 1.2 1.3 Introduccin .................................................................................................................. 5 Las pruebas en el ciclo de vida de un proyecto ......................................................... 6 Procedimientos, tipos y casos de pruebas ................................................................ 7

1.3.1 Planificacin de las pruebas ....................................................................................... 8 1.3.2 1.3.3 1.3.4 1.3.5 1.4 Diseo de las pruebas. Tipos de pruebas ............................................................ 10 Ejecucin de las pruebas ..................................................................................... 38 Finalizacin: evaluacin y anlisis de errores ...................................................... 40 Depuracin del cdigo fuente ............................................................................. 41

Herramientas para la realizacin de pruebas .............................................................. 44 Beneficios y problemas del uso de herramientas de pruebas ............................ 44 Algunas herramientas de pruebas de software .................................................. 45

1.4.1 1.4.2 2.

Herramientas para el control y documentacin de software.............................................. 47

Introduccin
Un usuario final de una aplicacin informtica no es conocedor de cmo ha sido implementada ni codificada. Lo ms importante para l o ella es que esta aplicacin haga lo que tenga que hacer, y, adems, que lo haga en el menor tiempo posible. Qu importancia tendr para un usuario utilizar dos productos que, en definitiva, ofrecen las mismas caractersticas? Imaginemos el caso de dos televisores. Si los dos reproducen los mismos canales y tienen las mismas pulgadas e idnticas caractersticas tcnicas, que nos har decidir si usar uno u otro? Posiblemente, en el caso de los televisores habr intangibles, como la marca o la esttica u otras caractersticas subjetivas. Pero, en el caso de las aplicaciones informticas o de las pginas web, cul puede ser el elemento que haga que una sea mejor que la otra si hacen exactamente lo mismo y tienen las mismas interfaces? En el caso del software, todo esto es algo abstracto; habr muchos intangibles que pueden hacer decantar hacia una aplicacin o hacia otra. Pero lo que seguro que ser diferente es la forma de haber creado y desarrollado estas aplicaciones. En esta unidad, "Optimizacin de software", veremos estas diferencias entre un cdigo de programacin normal y un cdigo optimizado, y estudiaremos las caractersticas que diferencian un tipo de cdigo de otro y las herramientas de las que se puede disponer para ello En el apartado "Diseo y realizacin de pruebas de software" se explican las diferentes formas y tcnicas que permiten validar la correccin del software desarrollado y su optimizacin. Hay muchas formas de poder crear aplicaciones que hagan lo que tienen que hacer y que cumplan los requisitos establecidos para los futuros usuarios. Y muchas veces, las diferencias en el momento de la creacin y del desarrollo de las aplicaciones harn que una se pueda considerar mucho mejor que la otra, y por lo tanto recomendable. Qu significa haber desarrollado mejor una aplicacin informtica? Significar que su cdigo de programacin sea ptimo, que haya seguido los patrones de optimizacin ms recomendados, que se hayan llevado a cabo todas las pruebas que hay que hacer para validar un funcionamiento correcto al 100%, que su desarrollo se haya documentado, habiendo un control de versiones exhaustivo y muchos otros detalles que se vern en esta unidad formativa. En cambio, una aplicacin informtica, sobre todo si es de cdigo abierto o se ha desarrollado a medida para una empresa externa o por el propio departamento de informtica de una organizacin, puede ser un producto vivo, en continua evolucin. Un da los informes se querrn ver de una forma u otra, o habr que aadir otros nuevos, otro da las reglas de negocio tendrn modificado y habr revisarlas para su desempeo. Otro, quizs, habr que modificar las funcionalidades que ofrece la aplicacin, ampliarla con unas nuevas y sacar otros.

En el apartado "Herramientas para el control y documentacin del software" trabajaremos algunas tcnicas que se utilizan para mejorar la calidad del cdigo de software por parte de los desarrolladores. Un ejemplo es la refactorizacin, pero tambin hay otros como el control de versiones o la documentacin automtica del software.

1.

Diseo y realizacin de pruebas de software

Las pruebas son necesarias en la fabricacin de cualquier producto industrial y, de forma anloga, en el desarrollo de proyectos informticos. Quin pondra a la venta una aspiradora sin estar seguro de que aspira correctamente? O una radio digital sin haber comprobado que pueda sintonizar los canales? Una aplicacin informtica no puede llegar a las manos de un usuario final con errores, y menos si stas son suficientemente visibles y claras como para haber sido detectadas por los desarrolladores. Se dara una situacin de falta de profesionalidad y disminuye la confianza por parte de los usuarios, que podra mermar oportunidades futuras. Cuando hay que llevar a cabo las pruebas? Qu hay que probar? Todas las fases establecidas en el desarrollo del software son importantes. La falta o mala ejecucin de alguna de ellas puede provocar que el resto del proyecto arrastre uno o varios errores que sern determinantes para su xito. Cuanto antes se detecte un error, menos costoso ser de solucionar. Tambin sern muy importantes las pruebas que se llevarn a cabo una vez el proyecto est finalizado. Es por ello que la fase de pruebas del desarrollo de un proyecto de software se considera bsica antes de hacer la transferencia del proyecto al usuario final. Quien dara un coche para construido y finalizado si al intentar arrancarlo no funcionara?

1.1

Introduccin

Cualquier miembro del equipo de trabajo de un proyecto informtico puede cometer errores. Los errores, adems, se podrn dar a cualquiera de las fases del proyecto (anlisis, diseo, codificacin ...). Algunas de estas errores sern ms determinantes que otros y tendrn ms o menos implicaciones en el desarrollo futuro del proyecto. Por ejemplo, un jefe de proyecto, a la hora de planificar las tareas del equipo, estipula el diseo de las interfaces en 4 horas de trabajo para un nico diseador. Si, una vez ejecutada esta tarea del proyecto, la duracin ha sido de 8 horas y se han necesitado dos diseadores, la repercusin en el desarrollo del proyecto ser una desviacin en tiempo y en coste, que quizs se podr compensar utilizando menos recursos o menos tiempo en alguna tarea posterior. En cambio, si el error ha sido del diseador de la base de datos, que ha obviado un campo clave de una tabla principal y su vinculacin con una segunda tabla, sta puede ser mucho ms determinante en las tareas posteriores. Si se crean las interfaces a partir de esta base de datos errnea y se empieza a desarrollar el software sin identificar el error, puede suceder que al cabo de unas cuantas tareas se detecte el error y que, por tanto, haya que volver al punto de inicio para solucionarla Las fases de desarrollo de un proyecto son: toma de requerimientos, anlisis, diseo, desarrollo, pruebas, finalizacin y transferencia. Un error no detectado al inicio del desarrollo de un proyecto puede llegar a necesitar cincuenta veces ms esfuerzos para ser solucionado si es detectado a tiempo.

En un proyecto de desarrollo de software est estipulado que se dedica entre un 30% y un 50% del coste de todo el proyecto en la fase de pruebas. Con este dato podemos darnos cuenta de la importancia de las pruebas dentro de un proyecto. Los resultados de las pruebas podrn influir en la percepcin que tendr el cliente final en relacin con el producto (software) entregado y su calidad. Precisamente, es el objetivo de estas pruebas: la evaluacin de la calidad del software desarrollado durante todo su ciclo de vida, validando que hace lo que debe hacer y que lo hace tal como se dise, a partir los requerimientos. 1.2 Las pruebas en el ciclo de vida de un proyecto En cada una de las fases del ciclo de vida de un proyecto, ser necesario que el trabajo llevado a cabo sea validado y verificado. En el esquema de la figura 1.1 podemos ver cmo encajan las pruebas en el ciclo de vida del software.

Figura 1.1. Ciclo de vida en V: fases de prueba

Depuradores Los depuradores (debuggers)son una aplicaciones o herramientas permiten la ejecucin controlada un programa o un cdigo, siguiendo el mando ejecutado y localizando los errores (bugs) Que puedan contener.

Cuando se avanza en el desarrollo del software se van planificando las pruebas que se harn en cada fase del proyecto. Esta planificacin se concretar en un plan de pruebas que se aplicar a cada producto desarrollado. Cuando se detectan errores en un producto se debe volver a la fase anterior para depurarlo y corregirlo, esto se indica con las flechas de vuelta de la parte izquierda de la figura.

Como se puede observar en la figura 1.1, El proceso de verificacin cubrir las fases de diseo e implementacin del producto. Las personas implicadas en su ejecucin sern los desarrolladores o programadores y el ingeniero de pruebas. Los desarrolladores harn pruebas sobre el cdigo y los diferentes mdulos que lo integran, y el ingeniero, sobre el diseo del sistema. Validacin es el trmino que se usa para evaluar positivamente si el producto desarrollado cumple los requisitos establecidos en el anlisis. Las personas encargadas de realizar las pruebas de validacin son los ingenieros de pruebas. Finalmente, el cliente debe dar el visto bueno al producto, por lo que se harn las pruebas de aceptacin en funcin de las condiciones que se firmaron al principio del contrato. 1.3 Procedimientos, tipos y casos de pruebas En cada una de las fases de un proyecto se tendr que dedicar un tiempo considerable a desarrollar las tareas y los procedimientos referentes a las pruebas. Es por ello que algunos autores consideran que los procedimientos relacionados con las pruebas son como un pequeo proyecto englobado dentro del proyecto de desarrollo. Este proyecto de pruebas requerir de una planificacin, un diseo del plan de pruebas, una ejecucin de las mismas y una evaluacin de los resultados, para analizar los errores y poder aplicar las acciones necesarias. En la figura 1.2 se muestra un esquema con los procedimientos que habr que llevar a cabo y la documentacin que se deber adjuntar. Este esquema servir como ndice para este apartado. El esquema se inicia con una planificacin de las pruebas, que tiene como punto de partida el anlisis funcional, diagramas de casos de uso del producto a desarrollar. En la planificacin se estimarn los recursos necesarios para la elaboracin de las pruebas y la posterior validacin del software, y se obtendr un plan de pruebas como salida. Partiendo del plan de pruebas y del cdigo fuente que se haya desarrollado, se llevar a cabo el diseo de las pruebas identificando qu tipo de pruebas se efectuar para cada una de las funcionalidades, y obtendrn, como salida, los casos de prueba y procedimientos. A partir de este momento, se crea un bucle donde se ejecutarn las pruebas, se evaluarn los resultados de las pruebas efectuadas detectando los errores, se depurar el cdigo aplicando las correcciones pertinentes y se volvern a ejecutar las pruebas. Al finalizar el bucle, se har el anlisis de la estadstica de errores. Este anlisis permitir hacer predicciones de la fiabilidad del software, as como detectar las causas ms habituales de error, con lo cual se podrn mejorar los procesos de desarrollo.

Figura 1.2. Proceso de pruebas

1.3.1 Planificacin de las pruebas La planificacin de las pruebas es una tarea que hay que ir desarrollando a lo largo de todas las fases del proyecto informtico. No hay que esperar la fase de programacin para crear este plan de pruebas, en la fase de anlisis y en la fase de diseo ya se tienen suficientes datos para poder comenzar a establecer las primeras lneas del plan de pruebas. Es importante tener presente que, cuanto antes se detecte una error al proyecto informtico, ms fcil ser contrarrestar y solucionar este error. El coste de la resolucin de un problema crece exponencialmente a medida que avanzan las fases del proyecto en las que se detecte. Pero, como sucede en muchos aspectos de la vida, una cosa es la teora y otra muy distinta la realidad. En muchas consultoras especializadas en desarrollo de software, as como en otras empresas ms pequeas o, incluso, por parte de programadores independientes que crean su propio software, se consideran las pruebas como un proceso que se trata al final del proyecto, una vez la mayor parte del cdigo ha sido desarrollado. La planificacin de las pruebas tiene como objetivo llegar a la creacin de un plan de actuacin que se refiera a cundo y cmo se llevarn a cabo las pruebas. Pero para ello es necesario llevar a cabo un anlisis minucioso del sistema y de sus elementos. El plan de pruebas debe contener todas las funciones, las estrategias, las tcnicas y los miembros del equipo de trabajo implicados. Una buena gua para determinar qu contendr un buen plan de pruebas se puede obtener de la normativa IEEE 829-2008 "Standard for Software and System Test Documentation". Este

estndar establece cmo deber ser la documentacin y los procedimientos que se utilizarn en las diferentes etapas de las pruebas del software. Algunos de los contenidos del plan de pruebas son: Identificador del plan de pruebas.Es el identificador que se asignar al plan de pruebas. Es importante para poder identificar fcilmente qu alcance tiene el plan de pruebas. Por ejemplo, si se quieren verificar las interfaces y procedimientos relacionados con la gestin de clientes, su plan de pruebas se podra decir PlaClients. Descripcin del plan de pruebas.Define el alcance del plan de pruebas, el tipo de prueba y sus propiedades, as como los elementos del software que se quieren probar. Elementos del software a probar.Determina los elementos del programa horario que se deben tener en cuenta en el plan de pruebas, as como las condiciones mnimas que deben cumplirse para llevarlo cabo. Elementos del software que no se deben probar. Tambin es importante definir los elementos que no se debern tener en cuenta el plan de pruebas. Estrategia del plan de pruebas.Define la tcnica a utilizar en el diseo de los casos de prueba, como por ejemplo la tcnica de caja blanca o de caja negra, as como las herramientas que se utilizarn o, incluso, el grado de automatizacin de las pruebas. Definicin de la configuracin del plan de pruebas.Define las circunstancias bajo las cuales el plan de pruebas podr ser alterado, finalizado, suspendido o repetido. Cuando se efecten las pruebas, se deber determinar cul es el punto que provoca que se suspendan, ya que no tendra mucho sentido continuar probando el software cuando ste se encuentra en un estado inestable. Una vez los errores han sido corregidos, se podr continuar efectuando las pruebas, es posible que se inicien desde el principio del plan o desde una determinada prueba. Finalmente, se podr determinar la finalizacin de las pruebas si stas han superado un determinado umbral. Documentos a entregar. Define los documentos a entregar durante el plan de pruebas y al finalizarlo. Esta documentacin debe contener la informacin referente al xito o fracaso de las pruebas ejecutadas con todo tipo de detalle. Algunos de estos documentos pueden ser: resultados de los casos de pruebas, especificacin de las pruebas, subplanes de pruebas ... Tareas especiales.Define las manchas necesarias para preparar y ejecutar las pruebas. Pero hay algunas tareas que tendrn un carcter especial, por su importancia o por su dependencia con otras. Para este tipo de tareas, ser necesario efectuar una planificacin ms detallada y determinar bajo qu condiciones se llevarn a cabo. Recursos. Por cada tarea definida en el plan de pruebas, deber asignarse uno o varios recursos, que sern los encargados de llevarla a cabo. Responsables y Responsabilidades.Se define el responsable de cada una de las tareas previstas en el plan.

 Calendario del plan de pruebas.En el calendario quedan descritas las tareas que debern ejecutar, indicando sus dependencias, los responsables, las fechas de actuacin y la duracin, as como las metas del plan de pruebas. Una herramienta muy utilizada para representar este calendario del plan de pruebas es el Diagrama de Gantt. Un error tpico es tratar la planificacin de pruebas como una actividad puntual, limitada al periodo de tiempo en que se elabora una lista de acciones para ser desarrolladas durante los prximos das, meses ... La planificacin es un proceso continuo y no puntual, por lo que hay que trabajar en l a lo largo de todo el proyecto, y para ello es necesario: Gestionar los cambios: no es de extraar que, a lo largo del ciclo de vida del proyecto, y con mayor probabilidad cuanto ms larga es la duracin, se presenten cambios en el alcance del proyecto. Ser necesario adaptar el plan de pruebas en las nuevas especificaciones. Gestionar los riesgos: Un riesgo se podra definir como un conjunto de situaciones que pueden provocar un impedimento o retraso en el plan de pruebas. Los riesgos debern identificar lo antes posible y analizar la probabilidad que existe de que sucedan, aplicando medidas preventivas, si se considera oportuno, o disponer de un plan de contingencia en caso de que el riesgo surgiera.

En la planificacin de un proyecto informtico el tiempo dedicado a las pruebas suele ser muy limitado.

De esta As, se puede afirmar que toda planificacin debe ser viva y hay que ir revisando y controlando de forma peridica. En caso de desviacin, se deben analizar las causas que lo han provocado y cmo afecta al resto de los proyectos. 1.3.2 Diseo de las pruebas. Tipos de pruebas El diseo de las pruebas es el siguiente paso despus de haber llevado a cabo el plan de pruebas. Este diseo consistir en establecer los casos de prueba, identificando, en cada caso, el tipo de prueba que se deber efectuar. Existen muchos tipos de pruebas: Estructurales o de caja blanca Funcionales o de caja negra De integracin De carga y aceptacin De sistema y de seguridad De regresin y de humo

Casos de prueba y procedimientos

A partir del plan de pruebas se debern especificado las partes de cdigo a tratar, en qu orden habr que hacer las pruebas, quien las har y mucha informacin ms. Ahora slo falta entrar en detalle, especificando el caso de prueba para cada una de las pruebas a realizar. Un caso de prueba define cmo se llevarn a cabo las pruebas, especificando, entre otros: el tipo de pruebas, las entradas de las pruebas, los resultados esperados o las condiciones bajo las cuales debern desarrollarse. Los casos de pruebas tienen un objetivo muy marcado: identificar los errores que hay en el software para que stos no lleguen al usuario final. Estos errores pueden encontrarse como defectos en la interfaz de usuario, en la ejecucin de estructuras de datos o un determinado requisito funcional. A la hora de disear los casos de prueba, no slo se ha de validar que la aplicacin hace lo que se espera ante entradas correctas, sino que tambin debe validar que tenga un comportamiento estable frente a entradas no esperadas , informando del error. Para desarrollar y ejecutar los casos de prueba en un proyecto informtico, podemos identificar dos enfoques: Pruebas de caja negra: se trata de ir probando todo el proyecto de forma independiente, funcin a funcin. El objetivo es validar que el cdigo cumple la funcionalidad definida. Pruebas de caja blanca: se trata de comprobar que todas las funciones encajan sin problemas para cumplir los objetivos del proyecto, es decir, deben garantizar que todas las piezas del proyecto encajan ajustndose a sus funcionalidades y los requerimientos establecidos.

Podemos observar que los casos de prueba nos permiten validar la aplicacin que se est desarrollando, siendo necesario tener accesible la documentacin generada en el anlisis funcional y el anlisis tcnico, as como en el diseo (casos de uso, diagramas de secuencia ...).

Los casos de prueba siguen un ciclo de vida clsico: Definicin de los casos de prueba. Creacin de los casos de prueba. Seleccin de los valores para los tests. Ejecucin de los casos de prueba. Comparacin de los resultados obtenidos con los resultados esperados.

Cada caso de prueba deber ser independiente de los dems, tendr un comienzo y un final muy marcado y deber almacenar toda la informacin referente a su definicin, creacin, ejecucin y validacin final.

A continuacin se indican algunas informaciones que debera contemplar cualquier caso de prueba: Identificador del caso de prueba. Mdulo o funcin a probar. Descripcin del caso de prueba detallado. Entorno que deber cumplir antes de la ejecucin del caso de prueba. Datos necesarios para el caso, especificando sus valores. Tareas que ejecutar el plan de pruebas y su secuencia. Resultado esperado. Resultado obtenido. Observaciones o comentarios despus de la ejecucin. Responsable del caso de prueba. Fecha de ejecucin. Estado (Finalizado, pendiente, en proceso).

Todo caso de prueba est asociado, como mnimo, a un procedimiento de prueba. Los procedimientos de prueba especifican como se podrn llevar a cabo los casos de prueba o parte de stos de forma independiente o de forma conjunta, estableciendo las relaciones entre ellos y el orden en que debern atender. Por ejemplo, se puede disear un procedimiento de prueba para insertar una nueva asignatura en la matrcula de un alumno; elaboran todos los pasos necesarios de forma consecutiva para actualizar la matrcula del alumno. Sin embargo, la asignatura puede ser obligatoria, optativa, con unas incompatibilidades ..., por lo tanto, en cuanto al procedimiento de prueba de insertar la matrcula ser necesario asociar un grupo de casos de prueba responsables de las diversas entradas de el usuario.

En la figura 1.3 se puede observar un esquema explicativo de las pruebas, desde la creacin del plan de pruebas hasta su ejecucin. Para cada parte del proyecto ser necesario crear un

diseo de las pruebas, a partir del cual se especificarn los casos de prueba y los procedimientos de prueba, que estn estrechamente ligados. Tras los procedimientos de prueba, el ltimo paso ser su ejecucin. Figura 1.3. Casos de pruebas y procedimientos

Tipos de pruebas Existen muchos tipos de pruebas que deben cubrir las especificaciones de un proyecto informtico a travs de los procedimientos y los casos de prueba. A continuacin se presenta un resumen de estos tipos de pruebas: Tipo de pruebas unitarias. Tienen las siguientes caractersticas: Son el tipo de pruebas de bajo nivel. Se llevan a cabo a medida que se va desarrollando el proyecto. Las efectan los mismos programadores. Tienen como objetivo la deteccin de errores en los datos, en los algo-mes y en la lgica de estos.

Las pruebas unitarias se podrn llevar a cabo segn un enfoque estructural o segn un enfoque funcional. El mtodo utilizado en este tipo de pruebas es el de la caja blanca o el de caja negra.

Tipo de pruebas funcionales. De estas pruebas hay que destacar: Son las encargadas de detectar los errores en la implementacin de los requerimientos de usuario. Las llevarn a cabo los verificadores y los analistas, es decir, personas distintas a aquellas que han programado el cdigo. Se efectan durante el desarrollo del proyecto. El tipo de mtodo utilizado es el funcional.

Tipo de pruebas de integracin. Sus caractersticas son las siguientes: Se llevarn a cabo posteriormente a las pruebas unitarias. Tambin las efectan los mismos programadores. Se llevan a cabo durante el desarrollo del proyecto. Se encargan de detectar errores de las interfaces y en las relaciones entre los componentes. El mtodo utilizado es el de caja blanca, el de diseo descendente y el de bottom-up.

Tipo de pruebas de sistemas. A destacar: Su finalidad es detectar errores en la consecucin de los requerimientos.

Las llevarn a cabo los verificadores y los analistas, es decir, personas distintas a aquellas que han programado el cdigo. Se efectan en una fase de desarrollo del software. El tipo de mtodo utilizado es el funcional.

Tipo de pruebas de aceptacin. Los aspectos ms importantes de estas pruebas son los siguientes: Su objetivo es la validacin o aceptacin de la aplicacin por parte de los usuarios. Es por ello que las llevarn a cabo los verificadores y los analistas, pero tambin los clientes, que sern los usuarios finales de las aplicaciones. Estas pruebas se llevarn a cabo una vez finalizada la fase de desarrollo, y es posible hacerlo en la fase previa a la finalizacin ya la transferencia o en la fase de produccin, mientras los usuarios ya utilizan la aplicacin. El tipo de mtodo utilizado tambin es el funcional.

Pruebas unitarias: enfoque estructural o de caja blanca Las pruebas unitarias, tambin conocidas como pruebas de componentes, son las pruebas que se harn a ms bajo nivel, sobre los mdulos o componentes ms pequeos del cdigo fuente del proyecto informtico. Estas pruebas pueden desarrollarse bajo dos enfoques: El enfoque estructural es la parte de las pruebas unitarias encargadas de la estructura interna del cdigo fuente, desde que se analizan todos los posibles caminos. El enfoque funcional (o pruebas de caja negra) es la parte de las pruebas unitarias encargadas del funcionamiento correcto de las funcionalidades del software.

Las pruebas de caja blanca se centran en la implementacin de los programas para escoger los casos de prueba. Lo ideal sera buscar casos de prueba que recorrieran todos los caminos posibles del flujo de control del programa. Estas pruebas se centran en la estructura interna del programa, analizando los caminos de ejecucin.

En la figura 1.4 se puede observar un esquema de la estructura que tienen las pruebas de caja blanca. A partir de unas condiciones de entrada al mdulo o parte de cdigo necesario validar que, yendo por la bifurcacin que se vaya, se obtendrn las condiciones deseadas de salida. Figura 1.4. Estructura de las pruebas de caja blanca

Las pruebas de caja blanca permitirn recorrer todos los posibles caminos del cdigo y ver qu sucede en cada caso posible. Se probar qu ocurre con las condiciones y los bucles que se ejecutan. Las pruebas se llevarn a cabo con datos que garanticen que han tenido lugar todas las combinaciones posibles. Para decidir qu valores debern tomar estos datos es necesario saber cmo se ha desarrollado el cdigo, buscando que no quede ningn rincn sin revisar. Partiendo del hecho de que las pruebas exhaustivas son impracticables, ya que el nmero de combinaciones es excesivo, se disean estrategias que ofrezcan una seguridad aceptable para descubrir errores. Los mtodos que se vern dentro de las pruebas de caja blanca son el de cobertura de flujo de control y el de complejidad Ciclomtica. Cobertura de control de flujo El mtodo de cobertura de flujo de control consiste en utilizar la estructura de control del programa para obtener los casos de prueba, que son diseados de manera que garanticen que al menos se pasa una vez por cada camino del programa. Una posible tcnica para llevar a cabo este mtodo consiste en obtener un diagrama de flujo de control que represente el cdigo y probar todos los caminos simples, todas las condiciones y todos los bucles del programa. Se puede observar un ejemplo de diagrama de flujo en la figura 1.5.

Puede ser imposible cubrir el 100% si el programa es muy complejo, pero podemos tener un mnimo de garantas de eficacia si seguimos las sugerencias para disear los casos de prueba fijndonos en estos elementos: Camino simple: Se ha de disear un caso de prueba para cada camino independiente, de manera que ejecute al menos una vez cada sentencia. Para ello es necesario determinar los posibles caminos independientes y preparar suficientes casos de prueba para recorrer todos los caminos. Condiciones: Deben disearse suficientes casos de prueba para todas las condi-ciones del programa que se evalan a verdadero / falso. Si las condiciones son mltiples, debern

dividirse en expresiones simples (una para cada operando lgico o comparacin), de manera que se debe probar que se cumpla o no cada parte de cada condicin. Bucles: Se deben disear los casos de prueba de manera que se intente ejecutar un bucle en diferentes situaciones lmite.

En la figura 1.5 se representan grficamente los nodos de la funcin, lo que facilita el clculo de la complejidad Ciclomtica. Figura 1.5. Diagrama de flujo del listado de asignaturas.

Complejidad Ciclomtica La estrategia de cobertura de flujo de control requiere disear casos de prueba suficientes para recorrer toda la lgica del programa. Se puede saber cuntos casos de prueba es necesario crear y ejecutar? Cmo se calcula? El matemtico Thomas J. McCabe llam complejidad Ciclomtica (CC) al nmero de caminos independientes de un diagrama de flujo, y propuso la siguiente frmula para calcularla: Complejidad Ciclomtica = nmero de ramas - nmero de nodos + 2 La complejidad Ciclomtica del grafo del ejemplo anterior, el de la figura 1.5, Proporciona el nmero mximo de caminos linealmente independientes. Los nodos que intervienen son 1, 2, 3, 4, 5, 6 y 7, y las ramas son las lneas que unen los nodos, que son un total de 8. complejidad Ciclomtica CC = 8-7 + 2 = 3 Esto significa que se debern disear tres casos de prueba. deberan tener en cuenta son: Camino 1: 1 - 2 - 3 - 4 - 5 - 6 - 2-7 Camino 2: 1 - 2 - 3 - 4 - 6 - 2-7 Camino 3: 1 - 2-7 Quedar generar las pruebas para recorrer los caminos anteriores. En la figura 1.6 se muestran los valores del vector de asignaturas. Hay tres caminos a recorrer. Para cada uno de ellos ser necesario un vector con una caractersticas concretas: Por recorrer el camino 1 ser necesario un vector de asignaturas que contenga como mnimo una asignatura que est disponible. Por recorrer el camino 2 ser necesario un vector de asignaturas que contenga como mnimo una asignatura que no est disponible. Por recorrer el camino 3 ser necesario un vector de asignaturas vaco. As, los tres recorridos que se

Figura 1.6. Valores del vector de asignaturas

Los resultados de las pruebas seran:

Entrada (Assignatures1) Salida esperada: 1 Salida real: 1 Camino seguido: 1.

Entrada (Assignatures2) Salida esperada: 1 Salida real: 1 Camino seguido: 2.

Entrada (Assignatures3) Salida esperada: 0 Salida real: 0 Camino continuacin: 3.

Una vez ejecutado el juego de prueba de caja blanca, se puede afirmar que han sido superadas satisfactoriamente. Pruebas unitarias: enfoque funcional o pruebas de caja negra El enfoque estructural o las pruebas de caja blanca, dentro de las pruebas unitarias, sirve para analizar el cdigo en todas sus estructuras, en todos sus caminos del software. Pero existe otro tipo de pruebas que se basa en un enfoque ms funcional, llamadas pruebas de caja negra. Las pruebas de caja negra prueban la funcionalidad del programa, para el que se disean casos de prueba que comprueben las especificaciones del programa. Las tcnicas de prueba de caja negra pretenden encontrar errores en funciones incorrectas o ausentes, errores de interfaz, errores de rendimiento, inicializacin y finalizacin. Se centra en las funciones y en sus entradas y salidas. En la figura 1.7 se puede observar un esquema de la estructura que tienen las pruebas de caja blanca.

Figura 1.7. Estructura de las pruebas de caja negra

Habr que elegir cuidadosamente los casos de prueba, de manera que sean tan pocos como sea posible para que la prueba se pueda ejecutar en un tiempo razonable y, al mismo tiempo, que cubran la variedad de entradas y salidas ms amplia posible. Para ello, se han diseado diferentes tcnicas: Clases de equivalencia:se trata de determinar los diferentes tipos de entrada y salida, agruparlos y elegir casos de prueba para cada tipo o conjunto de datos de entrada y salida. Anlisis de los valores lmite: Estudian los valores iniciales y finales, ya que estadsticamente se ha demostrado que tienen ms tendencia a detectar errores. Estudio de errores tpicos: La experiencia dice que hay una serie de errores que se suelen repetir en muchos programas, por lo que se tratara de disear casos de prueba que provocaran las situaciones tpicas de este tipo de errores. Manejo de interfaz grfica: Para probar el funcionamiento de las interfaces grficas, se deben disear casos de prueba que permitan descubrir errores en el manejo de ventanas, botones, iconos ... Datos aleatorias:se trata de utilizar una herramienta que automatice las pruebas y que genere de forma aleatoria los casos de prueba. Esta tcnica no optimiza la eleccin de los casos de prueba, pero si se hace durante bastante tiempo con muchos datos, podr llegar a hacer una prueba bastante completa. Esta tcnica se podra utilizar como complementaria a las anteriores o en casos en que no sea posible aplicar ninguna otra. Un ventaja de las pruebas de caja negra es que son independientes del lenguaje o paradigma de programacin utilizado, por lo que son vlidas tanto para programacin estructurada como para programacin orientada a objetos.

Clases de equivalencia

Se deben disear los casos de prueba de manera que prueben la mayor funcionalidad posible del programa, pero que no incluyan demasiados valores. Por dnde empezar? Qu valores se deben escoger?

Hay que seguir los siguientes pasos: 1. Identificar las condiciones, Restricciones o contenidos de las entradas y las salidas.

2. Identificar, a partir de las condiciones, las clases de equivalencia de las entradas y las salidas. Para identificar las clases, el mtodo propone algunas recomendaciones: Cada elemento de clase debe ser tratado de la misma manera por el programa, pero cada clase debe ser tratada de manera diferente en relacin con otra clase. Esto asegura que basta probar algn elemento de una clase para comprobar que el programa funciona correctamente para esta clase, y tambin garantiza cubriendo diferentes tipos de datos de entrada con cada una de las clases. Las clases deben recoger tanto datos vlidos como errneas,ya que el programa debe estar preparado y no bloquearse bajo ninguna circunstancia. Si se especifica un rango de valores para los datos de entrada, por ejemplo, si se admite del 10 al 50, se crear una clase vlida (10 X50) y dos clases no vlidas, una para los valores superiores (X>50) y la otra para los inferiores (X <10). Si se especifica un valor vlido de entrada y otras no vlidos, por ejemplo, si la entrada comienza con mayscula, se crea una clase vlida (con la primera letra mayscula) y otra no vlida (con la primera letra minscula). Si se especifica un nmero de valores de entrada, por ejemplo, si se han de introducir tres nmeros seguidos, se crear una clase vlida (con tres valores) y dos no vlidas (una con menos de dos valores y la otra con ms de tres valores) . Si hay un conjunto de datos de entrada concretas vlidas, se generar una clase para cada valor vlido (por ejemplo, si la entrada debe ser rojo, naranja, verde, se generarn tres clases) y otra por un valor no vlido (por ejemplo, azul). Si no se han recogido ya con las clases anteriores, se debe seleccionar una clase para cada posible clase de resultado. 3. Crear los casos de prueba a partir de las clases de equivalencia detectadas. Para ello se deben seguir los siguientes pasos: Elegir un valor que represente cada clase de equivalencia.

Disear casos de prueba que incluyan los valores de todas las clases de equivalencia identificadas.

La experiencia previa del equipo de pruebas puede ayudar a escoger los casos que ms probabilidades tienen de encontrar errores. Anlisis de valores lmite y errores tpicos Hay tcnicas que sirven para seleccionar mejor las clases de equivalencia. Una es el anlisis de los valores lmite. Por qu es una tcnica adecuada fijarse especialmente en los valores lmite? Se ha podido demostrar que los casos de prueba que se centran en los valores lmite producen un mejor resultado para la deteccin de defectos. De esta forma, al escoger el elemento representativo de la clase de equivalencia, en lugar de coger uno cualquiera, escogen los valores al lmite y, si se considera oportuno, un valor intermedio. Adems, tambin se intenta que los valores en la entrada provoquen valores lmite en los resultados. A la hora de escoger los representantes de cada clase se seguirn las siguientes recomendaciones: En los rangos de valores, coger los extremos del rango y el valor intermedio.

Si se especifican una serie de valores, coger el superior, el inferior, el anterior a la inferior y el posterior al superior. Si el resultado se mueve en un determinado rango, debemos escoger datos a la entrada para provocar las salidas mnima, mxima y un valor intermedio. Si el programa elige una lista o tabla, coger el elemento primero, el ltimo y el intermedio. Tambin se puede aprovechar la experiencia previa. Hay una serie de errores que se repiten mucho en los programas, y podra ser una buena estrategia utilizar casos de prueba que se centren en buscar estos errores. De esta manera, se mejorar la eleccin de los representantes de las clases de equivalencia: El valor cero suele provocar errores, por ejemplo, una divisin por cero bloquea el programa. Si se tiene la posibilidad de introducir ceros a la entrada, se debe escoger en los casos de prueba. Cuando se ha de introducir una lista de valores, habr que centrarse en la posibilidad de no introducir ningn valor, o introducir uno. Hay que pensar que el usuario puede introducir entradas que no son normales, por lo que es recomendable ponerse en el peor caso. Los desbordamientos de memoria son habituales, por eso hay que intentar introducir valores tan grandes como sea posible.

Uso de interfaz grfica No tan slo hay que hablar de entradas de textos, tambin hay que tener en cuenta los entornos grficos donde se llevan a cabo las entradas de valores o donde se visualizan los resultados. Actualmente, la mayora de programas suelen interactuar con el usuario haciendo uso de sistemas grficos que cada vez son ms complejos, con lo cual se pueden generar errores. Las pruebas de interfaz grfica de usuario deben incluir: Pruebas sobre ventanas: iconos de cerrar, minimizar ... Pruebas sobre mens y uso de ratn. Pruebas de entrada de datos: cuadro de texto, listas desplegables ... Pruebas de documentacin y ayuda del programa. Otros.

En la figura 1.9 se mostrauna ventana que controla el acceso al sistema de matriculacin de los alumnos mediante la introduccin de un nombre de usuario y una clave (password). El sistema comprueba si hay una cuenta con el nombre y clave especificado y, si es as, se da permiso para entrar. Si hay una cuenta con ese nombre y la clave es incorrecta, permite volver a introducir la clave hasta un mximo de tres veces. Figura 1.9. Pantalla para el control de entrada del identificador del alumno y de la clave para poder efectuar la matrcula

A continuacin se muestran algunos de los casos de prueba que se podran utilizar con este programa: Caso de prueba 1: Entrada: usuario correcto y la contrasea correcta. Pulsar el botn de acceder al sistema. Condiciones de ejecucin: en la tabla existe este usuario con la contrasea y con un intento fallido (nmero inferior a 3). -Resultado esperado: dar acceso al sistema y reflejar que el nmero de intentos para el usuario correcto es cero en la tabla USUARIO (cuenta, contrasea, n. intentos).

Caso de prueba 2:

Entrada: usuario incorrecto y contrasea correcta. Pulsar el botn de acceder al sistema. Condiciones de ejecucin: en la tabla no existe ese usuario con esta contrasea. Resultado esperado: no dar acceso al sistema.

Pruebas de integracin
Son suficientes las pruebas que se hacen en cada parte de una aplicacin para asegurarnos de que se ha validado el funcionamiento del software? La respuesta es no, es necesario validar tambin los diferentes mdulos combinados.

Pruebas de integracin

Una vez se han probado los componentes individuales del programa y se ha garantizado que no contienen errores, habr integrarlos para crear un sistema completo que tambin deber ser probado. Este es el nivel de las pruebas de integracin.

Un objetivo importante de las pruebas de integracin es localizar errores en las interfaces entre las diferentes unidades. Adems, las pruebas de integracin sirven para validar que las partes de cdigo que ya han sido probadas de forma independiente continen funcionando correctamente al ser integradas.

Los elementos no se integran todos al mismo tiempo, sino que se utilizan diferentes estrategias de integracin incremental, que, bsicamente, consisten en el que se muestra en el flujo de la figura 01:10. Figura 1.1o. Esquema de integracin incremental

Con este proceso se facilita la localizacin del error cuando se produzca, porque se sabe cules son los ltimos mdulos que se han integrado y cuando se produjo el error.

La organizacin clsica de los mdulos es una estructura jerrquica organizada por niveles: en la parte alta estar el mdulo o mdulos principales (a veces denominados padres), que hacen llamadas a mdulos subordinados de nivel inferior (hijos), y as sucesivamente cada nivel utilizar mdulos de nivel inferior hasta llegar a los mdulos terminales. Los mdulos superiores sern los ms cercanos al usuario, es decir, incluyen la interfaz de usuario (entorno grfico, mens, ayudas ...), y los mdulos inferiores son los ms cercanos a la estructura fsica del aplicacin (bases de datos, hardware ...). Existen diferentes estrategias de desarrollo de pruebas de integracin, como son las pruebas de integracin ascendente y las pruebas de integracin incrementales descendientes. Prueba de integracin ascendente Esta estrategia de desarrollo de las pruebas de integracin comenzar por los mdulos finales, los mdulos de ms bajo nivel, agrupndolos por sus funcionalidades. Se crear un mdulo impulsor que ir efectuando llamadas a los diferentes mdulos a partir de las precondiciones indicadas y recogiendo los resultados de cada llamada a cada funcin. A medida que los resultados de estas pruebas vayan saliendo positivos, se ir escalando por el rbol de jerarquas con el mdulo impulsor hacia los otros mdulos, haciendo las llamadas pertinentes de forma recursiva. La ltima prueba ser una llamada al software entero con los valores de entrada reales (analizando los valores tambin reales de salida).

A continuacin, se describe el proceso seguido para un sistema de informacin que tiene una estructura como la que se muestra en la figura 01:11: Figura 1.11. Esquema de pruebas de integracin ascendentes

En la figura 1.12 se puede observar la primera fase de las pruebas de integracin ascendentes. Cada mdulo debe ser probado por separado, por eso hay que construir un mdulo impulsor independiente para probar cada mdulo.

Figura 01:12. Integracin incremental ascendente, fase 1

La figura 01:13 muestra la siguiente fase, una vez finalizadas las pruebas sobre los mdulos de nivel ms bajo, los mdulos (07, 08, 12, 13, 14 y 11). El siguiente paso es continuar con los mdulos del siguiente nivel. Pero esto implica crear nuevos mdulos impulsores (04, 09, 10 y 06), que se aplicarn a estos mdulos, los cuales se integrarn con los mdulos de nivel ms bajo anteriormente probados (07, 08, 12, 13, 14 y 11). Figura 01.13. Integracin incremental ascendente, fase 2

La figura 1:14 muestra un nivel ms de esta estrategia, llegando a los mdulos 02, 05 y 03. Figura 1:14. Integracin incremental ascendente, fase 3

En la figura 1.15 se ve la integracin de los mdulos 04 y 05 con el mdulo 02, para lo cual se deber crear el impulsor 02, que llamar a este mdulo.

Figura 1:15. Integracin incremental ascendente, fase 4

En la figura 1.16 se ve como llega al final de este ejemplo de integracin incremental ascendente, hasta el mdulo 01, que integra los mdulos 02 y 03. Tambin habr que crear un impulsor 01 para la llamada de este mdulo.

Figura 1.16. Integracin incremental ascendente, fase 5

Adaptando el ejemplo que se trata en los puntos anteriores a las pruebas de integracin, si se quisieran efectuar las pruebas del proceso de matriculacin de los alumnos en un centro universitario, se podra empezar por los mdulos que hacen cambios en la base de datos o en el XML donde se almacena la informacin. Una vez que cada uno de estos mdulos funciona correctamente, se inician las pruebas de los mdulos de nivel superior, que bsicamente hacen llamadas a estos mdulos de nivel ms bajo (mdulos que podran tener la lgica de negocio). De forma progresiva, se irn incorporando nuevos mdulos hasta probar todo el sistema.

Ventajas de la integracin incremental ascendente Las ventajas son las siguientes:

 Orden adecuado: primero se evalan los mdulos inferiores, que son los que suelen tener el procesamiento ms complejo, se solucionan los errores, y luego se nutre de datos del resto del sistema. Ms sencillez: las entradas para las pruebas son ms fciles de crear, ya que los mdulos inferiores suelen tener funciones ms especficas. Mejor observacin de los resultados de las pruebas: como se empieza por los mdulos inferiores, es ms fcil la observacin de los resultados de las pruebas.

Desventajas de la integracin incremental ascendente Entre las desventajas, cabe destacar: Anlisis parcial: hasta que no se hace la llamada al ltimo mdulo no se valida el sistema como tal. Alto tiempo de dedicacin: habr que dedicar mucho tiempo a implementar cada mdulo impulsor, que pueden llegar a ser muchos.

Prueba de integracin incremental descendente

Esta estrategia de desarrollo de las pruebas de integracin comenzar por el mdulo de control principal (el ms importante, el de mayor nivel). Una vez validado, se irn integrando los otros mdulos que dependen de forma progresiva, sin seguir una estrategia concreta, slo teniendo en cuenta que el nuevo mdulo incorporado a las pruebas tendr ya validados todos los mdulos que lo referencian. En funcin del tipo de mdulos y del tipo de proyecto, se escoger una secuencia u otra a la hora de ir integrando mdulos, analizando el problema concreto. Las etapas de la integracin descendente son: Se selecciona el mdulo ms importante, el de mayor nivel. Este mdulo har de impulsor. Habr escribir otros mdulos ficticios que simulen los mdulos que llamar el principal. A medida que se van integrando mdulos, deber probarse independientemente y de forma conjunta con los otros mdulos ya probados. Una vez se ha finalizado la prueba, se sustituye el mdulo ficticio creado por el real que se ha integrado. Ahora habr que escribir los mdulos ficticios subordinados que se necesiten para la prueba del nuevo mdulo incorporado.

En la figura 01:17 se puede observar un esquema a partir del cual se llevarn a cabo las pruebas de integracin incremental descendente. En primer lugar, se combinarn los mdulos para formar los grupos 1, 2 y 3. Sobre cada grupo debern llevar a cabo las pruebas mediante un controlador. Los mdulos de los grupos 1 y 2 son subordinados del mdulo 02. Igualmente, se deber eliminar el controlador 3 del grupo 3 antes de la integracin con el mdulo 03. A continuacin, se integrar el mdulo 01 con el mdulo 02 y el mdulo 03. Estas acciones se irn repitiendo de forma recursiva a lo largo de toda la estructura del proyecto. Figura 01.17. Prueba de integracin incremental descendente

Ventajas de la integracin descendente Las ventajas son las siguientes: Identificacin de la estructura: permite ver la estructura del sistema desde un principio, facilitando la elaboracin de demostraciones de su funcionamiento.

 Diseo descendente: primero se definen las interfaces de los diferentes subsistemas para luego seguir con las funciones especficas de cada uno por separado.

Deteccin ms rpida de los errores que se encuentren en los mdulos superiores por el hecho de detectarse en una etapa inicial.

Desventajas de la integracin descendente Entre las desventajas, destaca:

Coste muy elevado: se implementarn muchos mdulos adicionales para ofrecer los mdulos ficticios a fin de ir efectuando las pruebas. Alta dificultad: al querer hacer una distribucin de las pruebas del ms genrico a lo ms detallado, los datos que se debern utilizar son difciles de conseguir, ya que son los mdulos de nivel ms bajo los que tendrn los detalles.

Pruebas de carga y aceptacin

El siguiente paso, una vez hechas las pruebas unitarias y las pruebas de integracin, ser llevar a cabo primero las pruebas de carga y, posteriormente, las pruebas de aceptacin. Las pruebas de carga son pruebas que tienen como objetivo comprobar el rendimiento y la integridad de la aplicacin ya terminada con datos reales. Se trata de simular el entorno de explotacin de la aplicacin. Con las pruebas anteriores (unitarias y de integracin) quedara probada la aplicacin a escala de "laboratorio". Pero tambin se necesita comprobar la respuesta de la aplicacin en situaciones reales, e incluso, en situaciones de sobrecarga, tanto a escala de rendimiento como de descontrol de datos. Por ejemplo, una aplicacin lenta puede ser poco operativa y no til para el usuario. Despus de las pruebas de carga, se encuentran las pruebas de aceptacin. Estas pruebas las realiza el cliente o usuario final de la aplicacin desarrollada. Son bsicamente pruebas funcionales, sobre el sistema completo, y buscan una cobertura de la especificacin de requisitos y del manual del usuario. Estas pruebas no se realizan durante el desarrollo, ya que sera impresentable de cara al cliente, sino una vez pasadas todas las pruebas anteriores por parte del desarrollador o el equipo de test.

Los programadores suelen obtener sorpresas en las pruebas de aceptacin, ya que es la primera vez que se encuentran con el programa finalizado. La objetivo de la prueba de aceptacin es obtener la aprobacin del cliente sobre la calidad de funcionamiento del sistema desarrollado y probado. La experiencia demuestra que, an despus del proceso ms cuidadoso de pruebas por parte del desarrollador y el equipo de trabajo, quedan una serie de errores que slo aparecen cuando el cliente pone en funcionamiento la aplicacin o el sistema desarrollado. Sea como sea, el cliente siempre tiene la razn. Por este motivo, muchos desarrolla-dores ejercitan unas tcnicas denominadas pruebas alfa y pruebas beta.

Las pruebas alfa consisten a invitar al cliente que venga en el entorno de desarrollo a probar el sistema. Se trabaja en un entorno controlado y el cliente siempre tiene un experto a mano para ayudarle a usar el sistema y para analizar los resultados.

Las pruebas beta vienen despus de las pruebas alfa, y se desarrollan en el entorno del cliente, un entorno que est fuera de control para el desarrollador y el equipo de trabajo. Aqu el cliente se queda solo con el producto y trata de encontrar los errores, de los que informar el desarrollador. Las pruebas alfa y beta son habituales en productos que se vendern a muchos clientes o que utilizarn muchos usuarios. Algunos de los compradores potenciales se prestan a estas pruebas, ya sea para ir entrenando a su personal con tiempo, ya sea en compensacin de alguna ventaja econmica (mejor precio sobre el producto acabado, derecho a mantenimiento gratuito, a nuevas versiones ...). La experiencia muestra que estas prcticas son muy eficaces. En un entorno de desarrollo de software tienen sentido cuando la aplicacin o sistema para desarrollar el usar un gran nmero de usuarios finales (empresas grandes con diferentes departamentos que tendrn que utilizar esta nueva herramienta).

Pruebas de sistema y de seguridad

Las pruebas de sistema son aquellas pruebas que se llevarn a cabo una vez finalizadas las pruebas unitarias (cada mdulo por separado), las pruebas de integracin de los mdulos, las pruebas de carga y las pruebas de aceptacin por parte del usuario. Temporalmente, se encuentran en una situacin en la que el usuario ha podido verificar la aplicacin desarrollada llevando a cabo las pruebas de aceptacin. Posteriormente, la aplicacin se ha integrado en su nuevo entorno de trabajo.

Las pruebas de sistema servirn para validar la aplicacin una vez sta haya sido integrada con el resto del sistema del usuario. Aunque la aplicacin ya haya sido validada de forma independiente, a las pruebas de sistema se llevar a cabo una segunda validacin con la aplicacin ya integrada en su entorno de trabajo real. A continuacin se enumeran algunos tipos de pruebas para desarrollar durante las pruebas del sistema: Pruebas de rendimiento: valorarn los tiempos de respuesta de la nueva aplicacin, el espacio que ocupar en el disco, el flujo de datos que generar a travs de un canal de comunicacin. Pruebas de resistencia: valorarn la resistencia de la aplicacin para determinadas situaciones del sistema. Pruebas de robustez: valorarn la capacidad de la aplicacin para soportar varias entradas no correctas. Pruebas de seguridad: ayudarn determinar los niveles de permisos de los usuarios, las operaciones que podrn llevarse a cabo y las de acceso al sistema ya los datos. Pruebas de usabilidad: determinarn la calidad de la experiencia de un usuario en la manera de interactuar con el sistema. Pruebas de instalacinInstalacin: indicarn las operaciones de arranque y de actualizacin de los programas. Las pruebas de sistema aglutinan muchas otras pruebas que tendrn varios objetivos: Observar si la aplicacin hace las funciones que tiene que hacer y si el nuevo sistema se comporta como debera hacerlo. Observar los tiempos de respuesta para las diferentes pruebas de rendimiento, volumen y sobrecarga. Observar la disponibilidad de los datos en el momento de recuperacin de un error (a la vez que la correccin). Observar la usabilidad.

Observar la instalacin (asistentes, operadores de arranque de la aplicacin, actualizaciones del software ...). Observar el entorno una vez la aplicacin est funcionando a pleno rendimiento (comunicaciones, interacciones con otros sistemas ...). Observar el funcionamiento de todo el sistema a partir de las pruebas globales realizadas. Observar la seguridad (control de acceso e intrusiones ...).

Las pruebas a escala global del sistema se han ido produciendo a medida que se tenan funcionalidades perfectamente acabadas. Es el caso, por ejemplo, de probar el funcionamiento correcto del desarrollo de una partida en uno de los tres juegos, o la navegacin correcta por las diferentes pantallas de los mens.

Las pruebas de validacin permiten comprobar si, efectivamente, se cumplen los requisitos propuestos por nuestro sistema.

Pruebas de regresin y pruebas de humo

Las pruebas de regresin buscan detectar posibles nuevos errores o problemas que puedan surgir en haber introducido cambios o mejoras en el software. Estos cambios pueden haber sido introducidos para solucionar algn problema detectado en la revisin del software a raz de una prueba unitaria, de integracin o de sistema. Estos cambios pueden solucionar un problema pero provocar a otros, sin haberlo previsto, en otros lugares del software. Es por esta razn que hay que llevar a cabo las pruebas de regresin al finalizar el resto de pruebas. Un control no conveniente de los cambios de versiones, o una falta de consideracin hacia otros mdulos o partes del software, pueden ser causas de los problemas para detectar en las pruebas de regresin. Se puede automatizar la deteccin de este tipo de errores con la ayuda de herramientas especficas. La automatizacin es complementaria al resto de pruebas, pero facilitar la repetibilidad. El problema que se puede derivar de la automatizacin de las pruebas de regresin es que pedirn un mantenimiento complejo. Las pruebas "De humo" se utilizan para describir la validacin de los cambios de cdigo en el software, antes de que los cambios en el cdigo se registren en la documentacin del proyecto.

Se acostumbra llevar a cabo una revisin del cdigo antes de ejecutar las pruebas de humo. Esta revisin del cdigo se har, sobre todo, en cuanto a los cambios que se hayan producido en el cdigo.

1.3.3 Ejecucin de las pruebas Despus de la planificacin de los procedimientos de pruebas y del diseo de los casos de pruebas, el siguiente paso ser el proceso de ejecucin. Este proceso est representado en el diagrama de flujo de la figura 01.18.

La ejecucin de las pruebas supondr seguir los siguientes pasos: 1. 2. 3. Ejecucin de las pruebas. Comprobacin de si se ha producido algn error en la ejecucin de las pruebas. Si no ha habido ningn error: Se verifica la finalizacin de las pruebas. Se valida si se necesitan pruebas adicionales. Si se necesitan pruebas adicionales, hay que validar que no existan condiciones anormales. Si hay condiciones anormales, se finaliza el proceso de pruebas haciendo una evaluacin del mismo proceso, si no, habr que depurar las pruebas. Si no se necesitan pruebas adicionales, se llevar a cabo una finalizacin del proceso de pruebas haciendo una evaluacin del mismo proceso. 4. En el caso de haber encontrado errores en la ejecucin de las pruebas, habr que ver si estos errores han sido debidos a: Un defecto del software. En este caso, la ejecucin de las pruebas ha cumplido su objetivo y habr depurar el cdigo de programacin, localizar el o los errores y solucionarlo para volver al punto inicial, en la que se volvern a ejecutar las pruebas y se volver a validar si el cambio efectuado ha sido exitoso. Pruebas "De humo" El cabo pruebas de humo surge a partir de la fabricacin de hardware. Si despus de reparar un componente de hardware, este "no echa humo", es que funcionar correctamente.

Un defecto del diseo de las pruebas. En este caso, habr que revisar las pruebas que se han ejecutado, depurndose las, localizando el o los errores y solucionarlo, por tener unas pruebas correctas, sin errores, listas para volver al punto inicial y volver a ejecutarlas.

Figura 1:18. Ejecucin de las pruebas

Una ejecucin de las pruebas exitosa no es aquella que encuentra errores a toda costa ni aquella que slo evala dos o tres posibilidades, sino que es aquella que cumple lo planificado en el plan de pruebas y que garantiza que lo diseado sea el que se valide.

1.3.4 Finalizacin: evaluacin y anlisis de errores

El ltimo paso de los procedimientos de pruebas ser la finalizacin del proceso. Para poder darlo por cerrado de forma exitosa, se deber efectuar una evaluacin y un anlisis de los errores localizados, tratados, corregidos y reevaluados.

Si no se puede dar por finalizado el proceso de pruebas, ser necesario llevar a cabo una replanificacin del proceso de pruebas para establecer nuevas depuraciones y nuevas pruebas, planificando y diseando de nuevo. En el caso de tener que rehacer los procedimientos de pruebas,es muy importante la creacin de nuevos casos de pruebas y no la readaptacin de los ya existentes. Si se crean nuevos casos de pruebas, estar rediseando los procedimientos de pruebas sobre el mismo cdigo fuente, si se intentan readaptar los ya existentes o modificar el cdigo, se corre el riesgo de hacer que el cdigo fuente sea el que se est adaptando a los casos de pruebas.

Finalmente, es conveniente escribir un informe que ayude a almacenar la experiencia que se ha recogido a lo largo del procedimiento de pruebas. Esta informacin ser muy importante para futuros proyectos, ya que ayudar a no volver a repetir los mismos errores detectados. El informe deber dar respuesta a tems como los que se indican a continuacin:

Nmero de casos de prueba generados. Nmero de errores detectados en cada fase del proyecto. Tiempo y recursos dedicados a los procedimientos de pruebas. Tipo de pruebas llevadas a cabo. Tipo de pruebas que ms errores han detectado. Nivel de calidad del software. Mdulos donde ms errores se han detectado. Errores que han llegado hasta los usuarios finales. Nmero de casos de prueba errneos detectados.

1.3.5 Depuracin del cdigo fuente

Las pruebas que se efectan sobre todo un proyecto informtico con todos los procesos involucrados (planificacin, diseo, ejecucin y evaluacin) ayudarn a la deteccin y correccin de errores, intentando encontrar a la mayor brevedad posible en el desarrollo del proyecto . Una tcnica muy importante para la ejecucin de las pruebas y, en general, para los programadores, es la depuracin del cdigo fuente.

La depuracin del cdigo fuente consiste a ir ejecutando paso a paso el cdigo fuente, observando los estados intermedios de las variables y los datos implicados para facilitar la correccin de errores.

Los procedimientos que estn vinculados a la depuracin del cdigo fuente son: Identificar la casustica para poder reproducir el error. Diagnosticar el problema. Solucionar el error atacando el problema.

Verificar la correccin del error y verificar que no se han introducido nuevos errores en el resto del software. La depuracin del cdigo es una herramienta muy til si se sabe localizar el mdulo o la parte del cdigo fuente donde se encuentra un determinado error. Si el error es difcil de reproducir ser muy complicado encontrar una solucin para solucionarlo. Por ello, acotando-lo dentro del cdigo, se puede ir localizando, haciendo pruebas para llegar a las circunstancias que lo reproducen. Habr que tener cuidado con las soluciones aplicadas cuando se usa la tcnica de la depuracin del cdigo. Muchas veces una modificacin en el cdigo para solucionar un problema puede generar otro error que est relacionado o que no tenga nada que ver. Habr que volver a confirmar la correcta ejecucin del cdigo una vez finalizada la correccin. La depuracin de cdigo permite la creacin de un punto en el cdigo fuente hasta el que el software ser ejecutado de forma directa. Cuando la ejecucin haya llegado a este punto de ruptura, se podr avanzar en la ejecucin del cdigo paso a paso hasta encontrar el error que se busca. Otra forma de llevar a cabo la depuracin de cdigo es ir hacia atrs, desde el punto del error, hasta encontrar el causante. Esta tctica se utiliza en casos ms complejos y no es tan habitual, pero ser muy til en el caso de no tener detectada la ubicacin del error, que puede encontrarse oculto en alguna parte del cdigo fuente. En estos casos, a partir del lugar donde se genera el error, se llevar a cabo un recorrido hacia atrs, yendo paso a paso en sentido inverso.

Una herramienta que ayuda a la depuracin del cdigo fuente es la utilizacin de ficheros llamados registros (logs). Estos ficheros, habitualmente de texto, registran toda la informacin vinculada a la ejecucin de un software con el objetivo de que el programador pueda hacer una revisin paso a paso de cmo ha evolucionado esta ejecucin y localizar errores o malos funcionamientos.

La depuracin del cdigo es bastante til tambin en la ejecucin de las pruebas de integracin, de sistema y de aceptacin. Eclipse proporciona un entorno de depuracin que facilita la deteccin de errores, permitiendo seguir el cdigo paso a paso y consultar los valores que van tomando los datos.

En la figura 1.19 se muestra el entorno de trabajo de la herramienta Eclipse a la hora de llevar a cabo las acciones de depuracin.

Figura 1:19. Eclipse: perspectiva de depuracin

1.4

Herramientas para la realizacin de pruebas

Las herramientas informticas para la realizacin de pruebas ayudarn mucho poder automatizar la tarea de ejecutar las pruebas y algunos de los otros procesos que hay que hacer para implementarlas (planificacin, diseo ...). Tal como sucede con las herramientas especficas para el desarrollo de software, tambin existen herramientas especficas para la ayuda a los procedimientos de pruebas. Esto s, como todo, el uso de estas herramientas tendr algunos puntos positivos, pero tambin conllevar algunos puntos dbiles.

1.4.1 Beneficios y problemas del uso de herramientas de pruebas LA ayuda que aportan las herramientas para la realizacin de pruebas es la de automatizar una tarea que muchas veces es muy repetitiva y puede llegar a reclamar mucho tiempo a los implicados en caso de hacerlo de forma manual. Adems, a medida que se van desarrollando las pruebas de forma manual, con el paso del tiempo, hay ms riesgo de que se produzcan errores humanos por parte de los desarrolladores o los verificadores.

La utilizacin de una herramienta que automatice las pruebas ofrece la posibilidad de generar los casos de pruebas, ejecutarlos y comparar los resultados obtenidos con los resultados esperados. Muchas veces, tantos datos tan parecidos favorecen la aparicin de errores, que con las herramientas informticas se pueden minimizar. Adems, son especialmente tiles para confirmar que un error se ha solucionado.

Las herramientas de ayuda a la elaboracin de pruebas ofrecen, tambin como puntos fuertes, una contraposicin a la repeticin de los errores a la hora de desarrollar las pruebas. Si un mismo programador ha desarrollado el cdigo fuente y es el encargado de generar los casos de prueba podr repetir, inconscientemente, los errores que ha cometido una vez. Si se usa un software para desarrollar un proyecto, y se quieren generar las pruebas con el mismo software, este mismo software las automatizar de tal manera que no se repitan los posibles errores de programacin. Esta consistencia y garanta a la hora de llevar a cabo las pruebas es ms difcil de ser mostrada por un ser humano. Otro punto fuerte de las herramientas de automatizacin de las pruebas son las funcionalidades que ofrecen a modo de resumen y que permiten tener ms informacin tanto de las pruebas como del cdigo desarrollado. Ser igual de importante la correcta realizacin de las pruebas como la informacin que se puede extraer y la forma de acceder. Una herramienta de gestin de pruebas puede ofrecer informes estadsticos sobre los resultados de las pruebas, sobre los diferentes mdulos evaluados, sobre los resultados, sobre las partes del cdigo fuente ms fiables y las que no ... Toda esta informacin, presentada de una forma adecuada, facilitar la toma de decisiones y la resolucin de problemas.

Como puntos dbiles en la utilizacin de herramientas de automatizacin de las pruebas se pueden encontrar:

Tiempo que hay que dedicar a aprender a utilizar correctamente este programa-rio. A veces es necesario dedicar tanto tiempo a conocer a conciencia una herramienta informtica como el que se dedicara a efectuar las pruebas de forma manual. Cada aplicacin informtica tiene sus caractersticas y sus especificaciones a la hora de ser utilizada. Se debern conocer bien para sacar el mximo provecho. Si no hay una buena configuracin y una buena seleccin de las pruebas, los resultados obtenidos de las herramientas en la realizacin de las pruebas tampoco sern fiables y se podran dar por buenos unos resultados que no lo son. Las aplicaciones son fiables si se saben utilizar correctamente. Dentro del proyecto, ser recomendable tener una persona que se dedique de forma exclusiva a esta tarea.

1.4.2 Algunas herramientas de pruebas de software

Las herramientas de pruebas del software se pueden clasificar segn muchos criterios: en funcin del o de los lenguajes de programacin a que se apoya, en funcin de si son privativos o de cdigo abierto, o en funcin, por ejemplo, del tipo de pruebas que permiten llevar a cabo. Se debe considerar que la gran mayora de los entornos integrados de desarrollo llevan integradas herramientas que permiten la depuracin del cdigo fuente. Algunas de ellas tambin permiten el desarrollo de pruebas o el hecho de aadir algn mdulo que lo permita.

A continuacin se enumeran algunas herramientas que permiten el desarrollo de pruebas en funcin del tipo de pruebas: Pruebas unitarias: JUnit. Automatiza las pruebas unitarias y de integracin. Provee clases y mtodos que facilitan la tarea de efectuar pruebas en el sistema para asegurar la consistencia y funcionalidad del software desarrollado. Pruebas estticas de cdigo: PMD. Puede ser integrado a diversas herramientas: JDeveloper, Eclipse, jEdit, etc. Permite encontrar en el cdigo errores en el manejo

de excepciones, cdigo muerto, cdigo sin optimizar, cdigo duplicado ... FindBugs. Puede integrarse Eclipse. Efecta un escaneo de cdigo mediante el cual encuentra errores comunes, malas prcticas de programacin, cdigo vulnerable, rendimiento, seguridad ... YASCA. Permite encontrar vulnerabilidades de seguridad, calidad en el cdigo, rendimiento ... Aprovecha la funcionalidad de los conectores FindBugs, PMD y Jlint. Pruebas de rendimiento: JMeter. Permite efectuar pruebas de rendimiento, de estrs, de carga y de volumen, sobre recursos estticos o dinmicos. OpenSTA. Permite captar las peticiones del usuario generadas en un navegador web, luego guardarlas, y poder editar para su posterior uso. WEbLoad.permite llevar a cabo pruebas de rendimiento, a travs de un entorno grfico en el que se pueden desarrollar, grabar y editar script de pruebas. Grinder.es un framework (Entorno de trabajo) escrito en Java, con el que se pueden efectuar pruebas de rendimiento, por medio descript escritos en lenguaje Jython. Permite grabar las peticiones del cliente sobre un navegador web para ser luego reproducido. Pruebas de aceptacin: Fitness. Permite comparar lo que debe hacer el software con el que realmente hace. Se pueden efectuar pruebas de aceptacin y pruebas de reglas de negocio. Avignon. Permite los usuarios expresar pruebas de aceptacin de una forma no ambigua antes de que comience el desarrollo. Trabaja en conjunto con JUnit, HTTPUnit ...

2.

Herramientas para el control y documentacin de software

Qu es ms importante, dedicar el menor tiempo posible en el desarrollo de una aplicacin informtica (y ahorrarnos todo el coste posible de un programador), o bien desarrollar la misma aplicacin con un cdigo fuente mucho ms optimizado y preparado para futuros cambios (habiendo dedicado ms esfuerzo)?

En el proceso de desarrollo de software es muy importante tener en cuenta ciertas directrices muy recomendables que, por otra parte, muchas veces no se siguen por falta de cultura y por la idea equivocada de que el hecho de seguirlas elevar los costos a nivel de tiempo.

Cunto cuesta tener un software desarrollado de forma ptima? Si un software hace lo que tiene que hacer, es eficaz y es eficiente, por qu es necesario que sea ptimo? Adems, si el desarrollo de un software hecho con prisas puede ahorrar tiempo de programadores, y el tiempo siempre es valorable en dinero, por qu se ha de invertir en desarrollar de forma ptima?

Las razones son muchas. Siempre costar lo mismo hacer las cosas mal hechas que hacerlas bien hechas, si te has acostumbrado a hacerlas bien hechas desde un principio y lo aprendido as. En un futuro, el mantenimiento y las posibles ampliaciones del software sern mucho ms costosas si has intentado ahorrar en tiempo antes.

Qu significa programar de forma ptima? Hay muchas cosas a tener en cuenta y se pueden encontrar muchos consejos al respecto.

2.1

Refactorizacin

Al desarrollar una aplicacin hay que tener muy presentes algunos aspectos del cdigo de programacin que se ir implementando. Hay pequeos aspectos que permitirn que este cdigo sea considerado ms ptimo o que facilitarn su mantenimiento. Por ejemplo, uno de estos aspectos ser la utilizacin de constantes. Si hay un valor que se usar varias veces a lo largo de un determinado programa, es mejor utilizar una constante que contenga este valor, de esta manera, si el valor cambia slo deber modificar la definicin de la constante y no habr irlo buscando por todo el cdigo desarrollado ni recordar cuntas veces se ha utilizado.

A continuacin, se muestra un ejemplo muy sencillo para entender a qu se hace referencia cuando se habla de optimizar el cdigo fuente:

1Class CalculCostos { 2 3 4 5 6} Public static double CostTreballadors (double NreTreballadors) { Return 1200 *NreTreballadors; }

En el cdigo anterior se muestra un ejemplo de cmo sera la codificacin de una clase que tiene como funcin el clculo de los costes laborales totales de una empresa. Se puede ver que el coste por trabajador no se encuentra en ninguna variable ni a ningn constante, sino que el mtodo CostTreballadors devuelve el valor que ha recibido por parmetro ( r r rs) por un nmero que considera el salario bruto por trabajador (en este caso supuesto 1.200 euros). Probablemente, este importe se utilizar adems clases durante el cdigo de programacin desarrollado o, como mnimo, ms veces dentro de la misma clase.

Como quedara el cdigo una vez aplicada la refactorizacin? Se puede ver a continuacin:

1Class CalculCostos { 2 3 final double SALARI_BRUT = 1,200; Public static double CostTreballadors (double NreTreballadors)

4 5 6 7}

{ Return SALARI_BRUT * NreTreballadors; }

Este es un ejemplo de lo que se entiende por refactorizacin.

El trmino refactorizacin hace referencia los cambios efectuados en el cdigo de programacin desarrollado, sin implicar ningn cambio en los resultados de su ejecucin. Es decir, se transforma el cdigo fuente manteniendo intacto su comportamiento, aplicando los cambios slo en la forma de programar o en la estructura del cdigo fuente, buscando su optimizacin.

El trmino refactorizacin fue utilizado por primera vez por William F. Opdyke a su tesis doctoral, en 1992, en la Universidad de Illinois.

A la figura 2.1 se puede ver un ejemplo de lo que se quiere expresar. Cul de las dos casas facilita ms la vida de sus inquilinos? Si hubiera que desarrollar una aplicacin informtica, a cul de las dos casas debera parecerse ms a la de la izquierda o la de la derecha? Figura 2.1. Diseo de una casa

Posiblemente las dos casas cumplen las especificaciones iniciales, edificio en el que se pueda vivir, pero parece que la primera casa ser ms confortable y ms ptima.

El trmino refactorizacin proviene del trmino refactoritzar (refactoring). Este trmino deviene de su similitud con el concepto de factorizacin de los nmeros o los polinomios. Es lo mismo tener 12 que tener 3 4, pero, en el segundo caso, el trmino 12 est dividido en sus factores (aunque se podra factorizar ms y llegar al 3 22). Otro ejemplo: el polinomio de segundo grado x2-1 es el mismo que el resultado del producto (x+ 1) (x- 1), pero en el segundo caso se ha dividido en factores. A la hora de simplificar o hacer operaciones, ser mucho ms sencillo el trabajo con el segundo caso (con los trminos ya factoritzats) que con el primero. Con la factorizacin aparecen unos trminos, unos valores, que inicialmente se encuentran ocultos, aunque forman parte del concepto inicial.

En el caso de la programacin sucede una situacin muy similar. Si bien el cdigo que se desarrolla no est factorizado, es decir, no se ven a simple vista los factores internos, porque son estructuras que aparentemente se encuentran escondidas, cuando se lleva a cabo una refactorizacin del cdigo fuente s se pueden ver.

2.1.1

Ventajas y limitaciones de la refactorizacin

La utilizacin de la refactorizacin puede aportar algunas ventajas a los desarrolladores de software, pero hay que tener en cuenta que tiene limitaciones que hay que conocer antes de tomar la decisin de utilizarla.

Ventajas de la refactorizacin

Hay muchas ventajas en la utilizacin de la refactorizacin, aunque tambin hay inconvenientes y algunas limitaciones. Por qu los programadores dedican tiempo a la refactorizacin del cdigo fuente? Una de las respuestas a esta pregunta es el aumento de la calidad del cdigo fuente. Un cdigo fuente sobre el que se han utilizado tcnicas de refactorizacin se mantendr en un estado mejor que un cdigo fuente sobre el que no se hayan aplicado. A medida que un cdigo fuente original se ha ido modificando, ampliando o manteniendo, habr sufrido modificaciones en la estructura bsica sobre la que se dise, y es cada vez ms difcil efectuar evolutivos y aumenta la probabilidad de generar errores.

Algunas de las ventajas o razones para utilizar la tcnica de refactorizacin del cdigo fuente son:

Prevencin de la aparicin de problemas habituales a partir de los cambios provocados por los mantenimientos de las aplicaciones.

Ayuda a aumentar la simplicidad del diseo.

Mayor entendimiento de las estructuras de programacin.

Deteccin ms sencilla de errores.

Permite agilizar la programacin.

Genera satisfaccin en los desarrolladores.

A continuacin, se desarrollan algunos de estos puntos fuertes de la utilizacin de la refactorizacin:

Deteccin y prevencin ms sencilla de errores.La refactorizacin mejora la robustez del cdigo fuente desarrollado, haciendo que sea ms sencillo encontrar errores en el cdigo o encontrar partes del cdigo que sean ms propensas a tener o provocar errores en el conjunto del software. A partir de la utilizacin de casos de prueba adecuados, se podr mejorar mucho el cdigo fuente. Prevencin de problemas por culpa de los mantenimientos del software.Con el tiempo, suelen surgir problemas a medida que se va aplicando un mantenimiento evolutivo o un mantenimiento correctivo de las aplicaciones informticas. Algunos ejemplos de estos problemas pueden ser que el cdigo fuente se vuelva ms complejo de entender de lo que sera necesario o que haya duplicidad de cdigo, debido a que, muchas veces, son personas diferentes las que han desarrollado el cdigo de las que estn llevando a cabo el mantenimiento. Comprensin del cdigo fuente y simplicidad del diseo. Volviendo a la situacin en la que un equipo de programacin puede estar compuesto por un nmero determinado de personas diferentes o que el departamento de mantenimiento de una empresa es diferente en el equipo de desarrollo de nuevos proyectos, es muy importante que el cdigo fuente sea muy fcil de entender y que el diseo de la solucin haya sido creado con una simplicidad considerable. Es necesario que el diseo se lleve a cabo teniendo en cuenta que se har una posterior refactorizacin, es decir, teniendo presentes posibles necesidades futuras de la aplicacin que se est creando. Esta tarea no es nada sencilla, pero con un buen y exhaustivo anlisis, por medio de muchas conversaciones con los usuarios finales, se podrn llegar a vislumbrar estas necesidades futuras. Programacin ms rpida. Precisamente, si el cdigo se comprende de una forma rpida y sencilla, la evolucin de la programacin ser mucho ms rpida y eficaz. El diseo llevado a cabo en la fase anterior tambin ser decisivo en el hecho de que la programacin sea ms gil.

Limitaciones de la refactorizacin

En cambio, se pueden encontrar varias razones para no considerar adecuada su utilizacin, ya sea por sus limitaciones o por las posibles problemticas que pueden surgir:

Personal poco preparado para utilizar las tcnicas de la refactorizacin. Exceso de obsesin para conseguir el mejor cdigo fuente. Excesiva dedicacin de tiempo a la refactorizacin, provocando efectos negativos.

Repercusiones en el resto del software y del equipo de desarrolladores cuando uno de ellos aplica tcnicas de refactorizacin. Posibles problemas de comunicacin provocados por el punto anterior. Limitaciones debidas a las bases de datos, interfaces grficas ...

Algunos de estos puntos dbiles relacionados con la utilizacin de la refactorizacin quedan desarrollados a continuacin:

Dedicacin de tiempo. Una actitud obsesiva con la refactorizacin podr llevar a un efecto contrario al que se busca: dedicar mucho ms tiempo del que sera necesario la creacin de cdigo y aumentar la complejidad del diseo y de la programacin innecesariamente.

Afectar o generar problemas al resto del equipo de programacin. Una refactorizacin de un programador puede generar problemas a otros componentes del equipo de trabajo, en funcin de donde se haya llevado a cabo esta refactorizacin. Si slo afecta a una clase oa algunos de sus mtodos, la refactorizacin ser imperceptible al resto de sus compaeros. Pero cuando afecta a varias clases, podr alterar de otro cdigo fuente que haya sido desarrollado o est desarrollando por parte de otros compaeros. Este problema slo se puede solucionar con una buena comunicacin entre los componentes del equipo de trabajo o con una refactorizacin sincronizada desde los responsables del proyecto, manteniendo informados a los afectados.

 Limitaciones debidas a las bases de datos.La refactorizacin tiene algunas limitaciones o reas conflictivas, como las bases de datos o las interfaces grficas. En el caso de las bases de datos, es un problema el hecho de que los programas que se desarrollan actualmente estn tan atados a sus estructuras. En el caso de haber modificaciones relacionadas con la refactorizacin en el diseo de la base de datos vinculada a una aplicacin, habra que llevar a cabo muchas acciones que complicaran esta actuacin: habra que ir a la base de datos, efectuar los cambios estructurales adecuados , hacer una migracin de los datos al nuevo sistema y adaptar de nuevo todo aquello de la aplicacin relacionado con los datos (formularios, informes ...).

Interfaces grficas. Una segunda limitacin se encuentra con las interfaces grficas de usuario. Las nuevas tcnicas de programacin han facilitado la independencia entre los distintos mdulos que componen las aplicaciones. De esta manera, se podr modificar el contenido del cdigo fuente sin tener que hacer modificaciones en el resto de mdulos, como por ejemplo, en las interfaces. El problema con la refactorizacin vinculado con las interfaces grficas radica en el hecho de que si esta interfaz ha sido publicada en muchos usuarios clientes o si no se tiene accesibilidad al cdigo que la genera, ser prcticamente imposible actuar sobre ella.

La refactorizacin se considera un aspecto muy importante para el desarrollo de aplicaciones mediante programacin extrema.

2.1.2

Patrones de refactorizacin ms usuales

El patrones se pueden encontrar en todas las versiones de Eclipse para los diferentes sistemas operativos (Windows, Linux y MacOS).

Los patrones, en un contexto de programacin, ofrecen una solucin durante el proceso de desarrollo de software a un tipo de problema o necesidad estndar que puede darse en diferentes contextos. El patrn dar una resolucin a este problema, que ya ha sido aceptada como solucin buena, y que ya ha sido bautizada con un nombre.

Por Por otra parte, ya ha quedado definida la refactorizacin como adaptaciones del cdigo fuente sin que ello provoque cambios en las operaciones del software. Si se unen estos dos conceptos se pueden encontrar algunos patrones existentes.

Como se puede observar en la figura 2.2, Todos los patrones se pueden llevar a cabo por medio del asistente de Eclipse. Figura 2.2. Eclipse: refactorizacin

Los patrones ms habituales son los siguientes:

Renombrar

Mover Extraer una variable local Extraer una constante Convertir una variable local en un campo Extraer una interfaz Extraer el mtodo

Renombrar

Este patrn cambia el nombre de variables, clases, mtodos, paquetes ... teniendo en cuenta sus referencias.

En el ejemplo de la figura 2.3, Se renombra el mtodo factorial con el nombre t r . Figura 2.3. Eclipse refactorizacin: renombrar

Mover

Este patrn mueve un mtodo de una clase a otra, mueve una clase de un paquete a otro ... teniendo en cuenta sus referencias. En el ejemplo de la figura 2.4, Mueve la funcin principal ( ), que se encuentra en la clase t r , hacia la clase . Figura 2.4. Eclipse refactorizacin: mover

Extraer una variable local

Dada una expresin, este patrn le asigna una variable local; cualquier referencia a la expresin en el mbito local ser sustituida por la variable. En el ejemplo, se asigna la expresin t r como el valor de la variable t t.

1public static void main (String [] args) { 2 3 ); 4 5 ); 6 } n = 5; System.out.println ("El factorial de "+ N +" es "+ calculFactorial (n) int n = 3; System.out.println ("El factorial de "+ N +" es "+ calculFactorial (n)

El cdigo refactoritzat es el que se muestra a continuacin:

1public static void main (String [] args) { 2 3 4 5 6 7 int n = 3; String texto = "El factorial de"; System.out.println (texto + N + "es" + calculFactorial (n)); n = 5; System.out.println (texto + N + "es" + calculFactorial (n)); }

Extraer una constante

Dada una cadena de caracteres o un valor numrico, este patrn lo convierte en una constante, y cualquier referencia ser sustituida por la constante. En el ejemplo, se asigna la expresin t r como el valor de la constante .

1public static void main (String [] args) { 2 3 ); 4 5 ); n = 5; System.out.println ("El factorial de "+ N +" es "+ calculFactorial (n) int n = 3; System.out.println ("El factorial de "+ N +" es "+ calculFactorial (n)

El cdigo refactoritzat es el que se muestra a continuacin:

1private static final String TEXTO = "El factorial de"; 2 3 4 5 6 7 8 public static void main (String [] args) { int n = 3; System.out.println (TEXTO + N + "es" + calculFactorial (n)); n = 5; System.out.println (TEXTO + N + "es" + calculFactorial (n)); }

Convertir una variable local en un campo

Dada una variable local, este patrn la convierte en atributo de la clase; cualquier referencia ser sustituida por el nuevo atributo. En el siguiente ejemplo se convierte la variable local r en un atributo de la clase t r .

1public class Factorial { 2 3 4 public static double calculFactorial (double n) { if (n == 0) return 1;

5 6 7 8 9 10 11 12 13 ); 14 15 ); 16 17 }

else { double resultado = N * calculFactorial (n-1); return resultado; } } public static void main (String [] args) { int n = 3; System.out.println ("El factorial de "+ N +" es "+ calculFactorial (n)

n = 5; System.out.println ("El factorial de "+ N +" es "+ calculFactorial (n)

El cdigo refactoritzat es el que se muestra a continuacin:

1public class Factorial { 2 3 4 5 6 7 8 private static int n; public static double calculFactorial (double n) { if (n == 0) return 1; else { double resultado = N * calculFactorial (n-1);

9 10 11 12 13 14 ); 15 16 ); 17 18 }

return resultado; } } public static void main (String [] args) { n = 3; System.out.println ("El factorial de "+ N +" es "+ calculFactorial (n)

n = 5; System.out.println ("El factorial de "+ N +" es "+ calculFactorial (n)

Extraer una interfaz

Este patrn crea una interfaz con los mtodos de una clase. En el ejemplo se crea la interfaz de la clase t r . 1public class Factorial { 2 3 4 5 public double calculFactorial (double n) { if (n == 0) return 1; else

Interfaz Una interfaz es un conjunto de mtodos abstractos y de propiedades. En las propiedades especifica qu hacer, pero no su implementacin. Sern las clases que implementen estas interfaces las que describan la lgica del comportamiento de los mtodos.

6 7 8 9 10 11 }

{ double resultado = N * calculFactorial (n-1); return resultado; } }

El cdigo refactoritzat es el que se muestra a continuacin:

1public interface InterficieFactorial { 2 3} public abstract double calculFactorial (double n);

1public class Factorial implementos InterficieFactorial { 2 3 4 / * (Non-Javadoc) *@ See InterficieFactorial # calculFactorial (double) */

5 6 7 8 9 10 11 12 13 14 15 }

@ Override public double calculFactorial (double n) { if (n == 0) return 1; else { double resultado = N * calculFactorial (n-1); return resultado; } }

Extraer el mtodo

Este patrn convierte un trozo de cdigo en un mtodo.

En el ejemplo, se convierte la variable local r como un atributo de la clase t r .

1public static void main (String [] args) { 2 3 4 5 int n = 3; int contador = 1; double resultado = 1; while (contador <= n) {

6 7 8 9 10

resultado = Resultado * contador; contador + +; } System.out.println ("Factorial de "+ N +": "+ calculFactorial (n)); }

El cdigo refactoritzat es el que se muestra a continuacin:

1private static void calcularFactorial (int n) { 2 3 4 5 6 7 8 9 10 11 12 13 int contador = 1; double resultado = 1; while (contador <= n) { resultado = Resultado * contador; contador + +; } } public static void main (String [] args) { int n = 5; calcularFactorial (n); System.out.println ("Factorial de "+ N +": "+ calculFactorial (n)); }

2.2

Pruebas y refactorizacin. Herramientas de ayuda a la refactorizacin

Las herramientas de ayuda a la creacin de software deben convertirse en aliadas en la tarea de ofrecer soluciones y facilidades para la aplicacin de la refactorizacin sobre el cdigo fuente que se est desarrollando. Otro ayuda muy importante la ofrecen los casos de prueba. Las pruebas que se habrn efectuado sobre el cdigo fuente son bsicas para validar el correcto funcionamiento del sistema y para ayudar a decidir si aplicar o no un patrn de refactorizacin.

Hay que tener cuidado con los casos de prueba escogidos. Habr que realicen algunas caractersticas que ayudarn a validar la correccin del cdigo fuente:

Casos de pruebas independientes entre mdulos, mtodos o clases.Los casos de prueba deben ser independientes para conseguir que los errores en una parte del cdigo fuente no afecten a otras partes del cdigo. De esta manera, se pueden llevar a cabo pruebas incrementales que verifiquen si los cambios que se han producido con los procesos de refactorizacin han comportado cambios en el resto del software. Los casos de pruebas deben ser automticos. Si hay diez casos de pruebas, no ser viable que se vayan ejecutando de forma manual uno a uno, sino que hay que se puedan ejecutar automticamente todos para que, posteriormente, se puedan analizar los resultados tanto de forma individual como de forma conjunta. Casos de pruebas autoverificables. Una vez que las pruebas se establecen de forma independiente entre los mdulos y que se pueden ejecutar de forma automtica, simplemente la verificacin de estas pruebas sea tambin automtica, es decir, que la propia herramienta verifique si las pruebas han sido satisfactorias o no . La herramienta indicar para qu casos de prueba ha habido problemas y en qu parte del cdigo fuente, para que el programador pueda tomar decisiones.

Por qu son tan importantes las pruebas para una buena ejecucin de la refactorizacin? Las pruebas y sus casos de pruebas son bsicos para indicar si el cdigo fuente desarrollado funcionar o no funcionar. Pero tambin ayudarn a saber hasta qu punto se pueden aplicar tcnicas de refactorizacin sobre un cdigo fuente determinado o no.

Se debe tener cuidado a la hora de utilizar estos casos de pruebas. Si no se aplican de forma adecuada, podrn suponer un problema ms que una ayuda. Hay que diferenciar mucho el cdigo fuente implementado del caso de prueba y que el vnculo entre ellos sea lo ms pequeo posible. Es importante verificar que el cdigo que implementa la prueba tenga una ejecucin exitosa, independientemente de cul haya sido su implementacin. Muchas veces, una refactorizacin en un cdigo fuente obliga a modificar los casos de prueba. Lo recomendable es aplicar refacciones paulatinamente, de forma ms continua, pero que sean pequeos cambios o que los cambios afecten a partes pequeas de cdigo.

Como habr que implementar la refactorizacin? Una propuesta de metodologa es la que se describe a continuacin:

Desarrollar el cdigo fuente. Analizar el cdigo fuente. Disear las pruebas unitarias y funcionales. Implementar las pruebas. Ejecutar las pruebas. Analizar cambios a efectuar. Definir una estrategia de aplicacin de los cambios. Modificar el cdigo fuente. Ejecucin de las pruebas.

Como se puede observar, esta metodologa parece una pequea gestin de proyectos dentro del propio proyecto de desarrollo de software. Habr que hacer un buen anlisis del cdigo fuente sobre el que se quieren llevar a cabo las pruebas, un diseo de los casos de prueba que se implementarn, as como una correcta ejecucin y un anlisis de los resultados obtenidos.

A continuacin se desarrolla, ms detalladamente, esta propuesta de metodologa:

 Desarrollo del cdigo fuente: esta parte no acontece propiamente parte de la metodologa para implementar la refactorizacin. Antes de llevar a cabo esta tcnica, habr que tener desarrollado el cdigo que se querr analizar. Analizar el cdigo fuente: una vez el software, o una parte de ste, ha sido desarrollado, ser necesario llevar a cabo un anlisis exhaustivo de este cdigo para comprobar si se detectan trozos de cdigo que se podr llevar a cabo la refactorizacin. Para determinar esto, la gran mayora de veces ser necesario disear y aplicar casos de prueba. Disear las pruebas unitarias y funcionales: antes de ejecutarlas, hay que escribir las pruebas. Pero antes de eso, ser necesario haber analizado el cdigo fuente (paso anterior) y diseado los casos de prueba. Llevar a cabo la refactorizacin sin haber ejecutado antes pruebas unitarias y pruebas funcionales puede llegar a resultar muy costoso y puede implicar un riesgo muy importante para el cdigo fuente desarrollado. Implementar y ejecutar las pruebas: una vez diseados los casos de pruebas, hay implementarlos y ejecutarlos. La razn de esta ejecucin es obtener ms informacin sobre cmo se comportar el software en las diferentes situaciones preparadas. Estas situaciones deben tener en cuenta varios escenarios, en situaciones extremas y en situaciones normales. El comportamiento actual del sistema, antes de efectuar cualquier cambio, deber ser el mismo comportamiento que una vez efectuada la refactorizacin.

Analizar cambios a efectuar: los casos de prueba han permitido ver cul es el comportamiento del software desarrollado, pero tambin ayudan a mostrar los cambios que se podrn efectuar en este software. Los resultados de las pruebas ofrecen informacin sobre los patrones de refactorizacin y de diseo que se podrn llevar a cabo. Adems de encontrar lugares en el cdigo que ofrecen indicaciones directas de mejora con la refactorizacin, los casos de prueba tambin ofrecen informaciones sobre otras refacciones no tan comunes, de las que los programadores no tienen tan clara su necesidad de mejora, pero que harn que el cdigo se vaya deteriorando de forma progresiva en el caso de no actuar a tiempo.

Definir una estrategia de aplicacin de los cambios: esta estrategia de actuacin deber aplicarse de forma progresiva. Hay que aplicar primero un conjunto de cambios para confirmar, a continuacin, la estabilidad del sistema, es decir, confirmar que los cambios no hayan provocado ningn otro problema o error. A continuacin, se llevar a cabo otro conjunto de cambios, y as sucesivamente, hasta finalizar todos. Hay actuaciones de refactorizacin ms sencillas de efectuar que otros, y otros cambios que atacan directamente los errores de diseo de la aplicacin. Por ejemplo, resolver problemas como el cdigo duplicado o las clases largas, con cambios pequeos y sencillos, permite que se solucionen los problemas importantes de diseo, lo que significar haber aportado mejoras grandes e importantes en el cdigo fuente.

 Modificar el cdigo fuente y ejecutar las pruebas: los cambios que se hayan producido al cdigo desarrollado muchas veces son muchos, pero pequeos. Si se hacen manualmente, se corre el riesgo de equivocarse. En cambio, utilizando herramientas especficas para aplicar los cambios de refactorizacin, se pueden efectuar de forma automtica sin ningn miedo a equivocarse. Una vez modificado el cdigo, habr que llevar a cabo la ejecucin de las pruebas. Esta vez la ejecucin validar que los casos de prueba ejecutados en este momento coincidan con los casos de prueba obtenidos anteriormente. De esta manera, se confirmar que los cambios efectuados no han afectado a los resultados esperados.

2.2.1

Herramientas para la ayuda a la refactorizacin

Actualmente, muchas IDE ofrecen herramientas que ayudan a la refactorizacin del cdigo fuente. Estas herramientas suelen estar integradas o permiten la descarga de mdulos externos o conectores. Con estos complementos se pueden llevar a cabo muchos de los patrones de refactorizacin de forma automtica o semiautomtica.

La clasificacin de estas herramientas se puede hacer a partir de muchos criterios diferentes, como el tipo de herramienta de refactorizacin (si es privativa o software libre), por las funcionalidades que ofrece (mirar cdigo duplicado, anlisis de la calidad del software , propuesta de ubicaciones en el cdigo fuente donde se pueden aplicar acciones de refactorizacin ...) oa partir de los lenguajes de programacin que permiten analizar.

A continuacin, se enumeran algunas de estas herramientas siguiendo la ltima clasificacin:

IDE, del ingls Integrated Development Environment, es un entorno de desarrollo integrado.

Java: RefactorIt, Condenser, JCosmo, Xrefactory, jFactor, IntelliJ IDEA.

Visual C + +, Visual C #, Visual Basic. NET, ASP.Net, ...: Visual Studio.

C + +: CppRefactory, Xrefactory.

C #:C # Refactoring Tool, C # Refactory.

SQL: SQL Enlight.

Delphi: Modelmaker tool, Castalia.

Smalltalk: RefactoringBrowser.

En la seccin Actividades web del mdulo se puede encontrar actividades de refactorizacin con Eclipse.

ERP

Un ERP (Enterprise Resource Planning) Es un sistema informtico que abarca toda una empresa, y que se utiliza para gestionar todos sus recursos y compartir la informacin entre los distintos departamentos en una nica base de datos.

LIDE Eclipse sirve como ejemplo de herramienta que permite llevar a cabo la refactorizacin, como se ha mostrado en apartados anteriores. Eclipse ya lleva integradas varias herramientas de refactorizacin en su instalacin estndar. Se pueden encontrar en el men principal, como un apartado propio llamado Refactor,o bien utilizando el men contextualizado mientras se trabaja con el editor.

2.3

Control de versiones

Por a un trabajo que no empieza y termina dentro de un perodo corto de tiempo, o para trabajos que deben ser desarrolladas por un equipo de personas, es recomendable tener un control de las tareas que se han hecho, cuando se han llevado a trmino, quien las ha hecho ...

Se habla de gestin de proyectos cuando se debe desarrollar un trabajo como el que se acaba de definir y, adems, se planifica. Qu tiene que ver la gestin de proyectos con el control de versiones de un software que se est desarrollando?

Tendr mucho que ver la analoga que tienen los dos procedimientos. Si el trabajo pedida es el cambio de la fuente de alimentacin de un ordenador, no habr ni planificarlo ni, probablemente, en caso de que se deje el trabajo a medias, habr que dejar documentada la situacin en que se encuentra el trabajo en cuestin. En cambio, si un programador debe implementar una calculadora, ser discutible decidir si necesitar una planificacin y una gestin de este trabajo como si fuera un proyecto (planificando, analizando, diseando y desarrollando) o si necesitar una herramienta que gestione las versiones desarrolladas hasta

el momento. Quizs llevar un control de versiones del software desarrollado le servir para poder volver atrs en caso de llegar a un punto de no retorno.

Cuando es muy recomendable utilizar un control de versiones (y, anlogamente, una gestin del proyecto)? En casos en que el desarrollo de software conlleva un trabajo de muchas horas, de muchos archivos diferentes y (aunque no necesariamente) la presencia de varias personas trabajando sobre el mismo proyecto, como por ejemplo en el desarrollo de un ERP (Enterprise Resource Planning).

Un sistema de control de versiones es una herramienta de ayuda al desarrollo de software que ir almacenando, segn los parmetros indicados, la situacin del cdigo fuente en momentos determinados. Es como una herramienta que va haciendo fotos de forma regular, cada cierto tiempo, sobre el estado del cdigo.

En un entorno donde slo trabajar un programador, slo habr que guardar la informacin del cdigo cada cierto tiempo o cada vez que l guarde la informacin, junto con los datos principales, como el nmero de la versin o la fecha y la hora en que se ha almacenado. En un entorno multiusuario, donde muchos programadores diferentes pueden manipular los archivos y donde, incluso, se podr ofrecer la posibilidad de modificar a la vez un mismo documento, en estos casos hay que almacenar mucha ms informacin, como qu usuario ha implementado los cambios, las referencias de la mquina desde donde se han realizado los cambios, si se est produciendo algn tipo de conflicto ... Esta funcionalidad no slo ser importante en los casos de desarrollo de software, sino tambin en muchos otros mbitos. Por poner unos ejemplos, se puede encontrar la importancia del control de versiones en el caso de trabajar en la creacin de un libro, colaborando varios autores en su redaccin. Si queda registrado en qu momento ha hecho cada cambio cualquier colaborador diferente, y, adems, queda registrada una copia de cada modificacin hecha, esto permitir al resto de colaboradores tener una informacin muy importante para no repetir contenidos ni duplicar trabajos. Un ejemplo real para el que se acaba de explicar se puede encontrar en la redaccin de contenidos de la Wikipedia, donde muchos redactores crean contenidos mediante una herramienta que permite el trabajo en equipo y el control de los contenidos creados y colgados. Otro caso se puede encontrar en una gestora o un bufete de abogados que han de redactar un contrato o un documento en colaboracin con uno o varios clientes. En este caso, no ser necesario utilizar una herramienta como una wiki, puede ser suficiente usar un buen editor de textos que permita la funcionalidad

de gestin de cambios, donde cada vez que un usuario diferente tenga que hacer un cambio, quede indicado en el documento con un color diferente en funcin del usuario que lo cre.

En el desarrollo de software, los sistemas de control de versiones son herramientas que pueden facilitar mucho el trabajo de los programadores y aumentar la productividad de forma considerable, siempre que estas herramientas sean utilizadas de forma correcta. Algunas funcionalidades de los sistemas de control de versiones pueden ser:

Comparar cambios en los diferentes archivos a lo largo del tiempo,pudiendo ver quin ha modificado por ltima vez un determinado archivo o trozo de cdigo fuente.

Reduccin de problemas de coordinacin que puede haber entre los diferentes programadores.Con los sistemas de control de versiones podrn compartir su trabajo, ofreciendo las ltimas versiones del cdigo o de los documentos, y trabajar, incluso, de forma simultnea sin miedo a encontrarse con conflictos en el resultado de esta coleccinracin.

Posibilidad de acceder a versiones anteriores de los documentos o cdigo fuente.De forma programada se podr automatizar la generacin de copias de

seguridad o, incluso, almacenar todo cambio efectuado. En el caso de haberse equivocado de forma puntual, o durante un perodo largo de tiempo, el programador podr tener acceso a versiones anteriores del cdigo o deshacer, paso a paso, todo lo desarrollado durante los ltimos das. Ver qu programador ha sido el ltimo en modificar un determinado trozo de cdigo que puede estar causando un problema.

Acceso en el historial de cambios sobre todos los archivos a medida que avanza el proyecto. Tambin puede servir para el fin de proyectos o para cualquier otra parte interesada (stakeholder), Con permisos para acceder a este historial, para ver la evolucin del proyecto. Volver un archivo determinado o todo el proyecto entero a uno o varios estados anteriores.

Los sistemas de control de versiones ofrecen, adems, algunas funcionalidades para poder gestionar un proyecto informtico y para poder hacer el seguimiento. Entre estas funcionalidades se pueden encontrar:

Control histrico detallado de cada archivo. Permite almacenar toda la informacin de lo que ha sucedido en un archivo, como todos los cambios que se han efectuado, por quin, el motivo de los cambios, almacenar todas las versiones que ha habido desde su creacin ... Control de usuarios con permisos para acceder a los archivos. Cada usuario tendr un tipo de acceso determinado a los archivos para poder consultarlos o modificarlos o, incluso, borrarlos o crear otros nuevos. Este control debe ser gestionado por la herramienta de control de versiones, almacenando todos los usuarios posibles y los permisos que tienen asignados. Creacin de ramas de un mismo proyecto: en el desarrollo de un proyecto hay momentos en que hay ramificarse lo, es decir, a partir de un determinado momento, de un determinado punto, hay que crear dos ramas del proyecto que se podrn seguir desarrollando por separado. Este caso puede darse en el momento de finalizar una primera versin de una aplicacin que se entrega a los clientes, pero que hay que seguir evolucionando. Fusionar dos versiones de un mismo archivo: permitiendo fusionarlas, cogiendo, de cada parte del archivo, el cdigo que ms interese a los desarrolladores. Esta funcionalidad se deber validar manualmente por parte de una persona.

2.3.1

Componentes de un sistema de control de versiones

Un sistema de control de versiones se compondr de diversos elementos o componentes que usan una terminologa un poco especfica. A continuacin, quedan definidos algunos de estos elementos:

 Repositorio: conjunto de datos almacenados, tambin referido a versiones o copias de seguridad. Es el lugar donde estos datos quedan almacenados. Se podr referirse a muchas versiones de un nico proyecto o de varios proyectos. Mdulo: se refiere a una carpeta o directorio especfico del repositorio. Un mdulo podr hacer referencia a todo el proyecto entero o slo a una parte del proyecto, es decir, a un conjunto de archivos. Revisin: es cada una de las versiones almacenadas de un determinado proyecto; podr hacer referencia a todos los archivos de un proyecto que componen una versin determinada en un instante de tiempo o los archivos que han sido modificados desde la ltima versin. Etiqueta: informacin que se aadir un mdulo para indicar alguna caracterstica especfica que lo hace especial. Esta informacin ser textual y, muchas veces, se har de forma manual. Tambin podr utilizarse para localizar un conjunto de archivos que componen una revisin completa y que se quieren tener localizados o para poder referenciar desde otra versin. Rama: se utilizar para llevar a cabo un anlisis de las revisiones almacenadas sin afectar las revisiones en curso. Para lograr esto, hay que hacer una copia de un mdulo o una revisin entera para poder trabajar en paralelo. A esta copia se le llamar rama. Directorio de trabajo: el programador trabajar sobre este directorio a partir de una copia que habr hecho del repositorio en su ordenador local.

2.3.2

Clasificacin de los sistemas de control de versiones

Se puede generalizar la estructura de las herramientas de control de versiones teniendo en cuenta la clasificacin de los sistemas de control de versiones, que pueden ser locales, centralizados o distribuidos.

Sistemas locales

Los sistemas de control de versiones locales son sistemas que permiten llevar a cabo las acciones necesarias de forma local. Si no se utiliza ningn sistema de control de versiones concreto, un programador que trabaje en su propio ordenador podr ir haciendo copias de seguridad, de vez en cuando, los archivos o de las carpetas con las que trabaje. Este sistema implica dos caractersticas especficas:

El mismo programador ser la persona que deber recordar que ir haciendo las copias de seguridad cada cierto tiempo, lo que l haya establecido. El mismo programador deber decidir donde llevar a cabo estas copias de seguridad, muy probablemente en local, en otra ubicacin del disco duro interno, o en un dispositivo de almacenamiento externo.

Este sistema tiene un alto riesgo porque es un sistema altamente dependiente del programador, pero es un sistema extremadamente sencillo de planificar y ejecutar. Lo habitual en estos casos, es crear copias de seguridad (que se pueden considerar versiones del proyecto), los archivos se almacenan en carpetas que suelen tener un nombre representativo, como por ejemplo: la fecha y la hora en que se efecta la copia. Pero, tal como se ha comentado anteriormente, se trata de un sistema propenso a errores por diversos motivos, como que se produzcan olvidos en la realizacin de la copia de seguridad, o confusiones que lleven al programador a continuar el desarrollo en una de las copias del cdigo, e ir avanzando con el proyecto en diferentes ubicaciones diferentes das.

Para hacer frente a estos problemas, aparecieron los primeros repositorios de versiones que contenan una pequea base de datos donde se podan registrar todos los cambios efectuados, sobre qu archivos, quien los haba hecho, cuando ... Efectuando las copias de seguridad de forma automatizada.

En la figura 2.5 se puede observar la representacin del sistema local, con los archivos y sus copias o versiones. Figura 2.5. Sistema de control de versiones locales

Sistemas centralizados

Un sistema de control de versiones que permita desarrollar un proyecto informtico con ms de un ordenador es el sistema de control de versiones centralizado que se contrapone a otro sistema de control de versiones, tambin para ms de un ordenador, como es el distribuido.

En los sistemas centralizados habr ms de un programador desarrollando un proyecto en ms de un ordenador. Desde los dos ordenadores se podr acceder a los mismos archivos de trabajo y sobre las mismas versiones almacenadas. Esta es una situacin ms cercana a las situaciones actuales reales en el desarrollo de proyectos informticos.

El sistema de control de versiones centralizado es un sistema donde las copias de seguridad o versiones almacenadas se encuentran de forma centralizada en un servidor que ser accesible desde cualquier ordenador que trabaje en el proyecto. En la figura 2.6 se puede observar cmo se representa este sistema de control de versiones centralizado. Figura 2.6. Sistema de control de versiones centralizado

Pero este sistema tambin tendr sus inconvenientes, a veces muy difciles de salvar. Qu ocurre si falla el servidor central? Si es un fallo temporal no se podr acceder durante un pequeo periodo tiempo. Si es un fallo del sistema, habr que tener preparado un sistema de recuperacin o un sistema alternativo (una copia). Durante este tiempo, los diferentes desarrolladores no podrn trabajar de forma colaborativa ni acceder a las versiones almacenadas ni almacenar otras nuevas. Este es una desventaja difcil de contrarrestar.

Como el repositorio se encuentra centralizado en un nico ordenador y una nica ubicacin, la creacin de una ramas se llevar a cabo en la misma ubicacin que el resto del repositorio, utilizando una nueva carpeta para crear la duplicidad. Los puntos dbiles con el trabajo de las ramas sern los mismos que se han expuesto en general para los sistemas de control de versiones centralizados.

Sistemas distribuidos

Los sistemas de control de versiones distribuidos ofrecen una solucin a esta desventaja ofrecido por los sistemas de control de versiones centralizados. Como se puede ver en la figura 2.7, La solucin que ofrecen los sistemas distribuidos es disponer cada ordenador de trabajo, as como el servidor, de una copia de las versiones almacenadas. Esta duplicidad de las versiones ofrece una disponibilidad que disminuye muchsimo las posibilidades de no tener accesibilidad a los archivos ya sus versiones.

Figura 2.7. Sistema de control de versiones distribuido

Cul es la forma de trabajar de este sistema? Cada vez que un ordenador cliente accede al servidor para tener acceso a una versin anterior, no slo copian ese archivo, sino que hacen una descarga completa de los archivos almacenados.

Si el servidor tiene un fallo del sistema, el resto de ordenadores clientes podrn continuar trabajando y cualquiera de los ordenadores clientes podr efectuar una copia entera de todo el sistema de versiones al servidor para restaurarlo. La idea es que el servidor es el que gestiona el sistema de versiones, pero en caso de necesidad puede acceder a las copias locales que se encuentran en los ordenadores clientes.

2.3.3

Operaciones bsicas de un sistema de control de versiones

Entre las operaciones ms habituales de un sistema de control de versiones (tanto en los sistemas centralizados como en los distribuidos) se pueden diferenciar dos tipos: aqullas que permiten la entrada de datos al repositorio y aquellas que permiten obtener datos del repositorio. En la figura 2.8 se muestra un resumen de estas operaciones.

Entre las operaciones de introduccin de datos en el repositorio se pueden encontrar:

Importacin de datos: esta operacin permite llevar a cabo la primera copia de seguridad o versionado de los archivos con los que se trabajar en local hacia el repositorio. Subir (commit): esta operacin permite enviar, en el repositorio, los datos correspondientes a los cambios que se han producido en el servidor local. No se har una copia entera de toda la informacin, sino que slo se trabajar con los archivos que se hayan modificado en el ltimo espacio de tiempo.

Entre las operaciones de exportacin de datos del repositorio se pueden encontrar:

Bajar (check-out): con esta operacin podr tener acceso y descargan pagar una versin de trabajo de un archivo, un mdulo o una revisin a un equipo cliente. Actualizacin (update): esta operacin permite llevar a cabo una copia de seguridad de todos los datos del repositorio en el ordenador cliente con el que trabajar el programador. Ser una operacin que se podr efectuar de forma manual, cuando el programador lo estime oportuno, o de forma automtica, como en los sistemas distribuidos, donde cada vez que un cliente accede al repositorio se hace una copia completa en local.

Figura 2.8. Operaciones que se pueden hacer en un sistema de control de versiones

2.4

Herramientas de control de versiones

Por llevar a cabo un control de versiones automatizado existen varias herramientas que facilitan mucho este trabajo. Estas herramientas pueden ser independientes al resto de las herramientas que se utilizarn para la gestin y el desarrollo del proyecto informtico o se pueden encontrar integradas con otras herramientas, como Visual Studio o Eclipse, facilitando as el trabajo de los miembros de la equipo del proyecto. Las funcionalidades que ofrecen pueden ir desde el control del cdigo fuente, la configuracin y gestin del cambio, la administracin de versiones de archivos y de directorios de un proyecto, hasta la integracin completa de los proyectos, analizando, planificando, compilando, ejecutando y probando de forma automtica los proyectos.

Algunas herramientas de control de versiones son:

Team Foundation Server. Esta herramienta ha sido desarrollada por Micro-soft, lo que implica que sea una herramienta privativa. Es una herramienta preparada para trabajar en colaboracin con Visual Studio 2010. Permite acciones de control de cdigo, administracin del proyecto, seguimiento de los elementos de trabajo y gestin de los archivos a partir de un portal web del proyecto. Se trata de una evolucin de la herramienta Visual Source Safe.

CVS - Concurrent Versions System. Esta herramienta ofrece un sistema de control de versiones con una serie de funcionalidades que ayudan al programador:

Mantenimiento del registro de todo el trabajo por parte de los miembros del equipo del proyecto. Grabacin de todos los cambios en los ficheros.

Permite el trabajo en equipo en colaboracin por parte de desarrolladores a gran distancia.

Subversion. Herramienta de Cdigo Abierto, independiente del sistema operativo de la mquina en que se utilice. Herramienta desarrollada en 2000 con el objetivo de sustituir CVS. Aade nuevas funcionalidades y mejora algunas otras que no acababan de funcionar adecuadamente coon la herramienta CVS. Disponible para varios sistemas operativos, como la distribucin RedHat, MacOS ...

MyLyn. Herramienta de control de versiones que es una extensin del IDE Eclipse. Permite tanto la gestin del proyecto como la gestin de las versiones. Disponible para Linux y MacOS X.

Git. Herramienta de Gestin de Versiones desarrollada por programadores del ncleo de Linux. Desarrollada a partir de evoluciones de la herramienta CVS, ya que el Subversion no cubra las necesidades de los desarrolladores de proyectos Linux.

2.4.1 Otras herramientas

Existen muchas otras herramientas para la ayuda del control de versiones. Algunas se pueden clasificar en funcin del lenguaje de programacin al que asisten y otros se pueden clasificar en funcin del o de los sistemas para la que fueron desarrolladas. Puede ver a continuacin otras herramientas de sistema de gestin de versiones, clasificadas en funcin de si pertenecen a software libre o privativo:

Software libre:

GNU Arch Redmine Mercurial (ALSA, MoinMoin, Mutt, Xen) PHP Collab Git Mylyn CVS Subversion

Software privativo:

Clear Case Darcs Team Fundation Server

2.5

Depsitos de las herramientas de control de versiones

Un depsito es un almacn de datos donde se guardar todo lo relacionado con una aplicacin informtica o unos datos determinados de un determinado proyecto.

LEl uso de depsitos no es una tcnica exclusiva de las herramientas de control de versiones. Las aplicaciones y los proyectos informticos suelen utilizar depsitos que contienen informacin. Por ejemplo, un depsito con informacin referente a una base de datos contendr todo lo referente a cmo est implementada esta base de datos: qu tablas tendr, qu campos, como sern estos campos, sus caractersticas, sus valores lmites ...

En el mbito del control de versiones, tener este depsito supone poder contar con un almacn central de datos que guarda toda la informacin en forma de ficheros y de directorios, y que permite llevar a cabo una gestin de esta informacin.

Toda herramienta de control de versiones tiene un repositorio que es utilizado como un almacn central de datos. La informacin almacenada ser toda la referente al proyecto informtico que estar desarrollando. Los clientes se conectarn a este repositorio para leer o escribir esta informacin, accediendo a informacin de otros clientes o haciendo pblica su propia informacin. En la figura 2.9 se muestra un ejemplo conceptual de un repositorio centralizado donde acceden varios clientes para escribir o leer archivos. Figura 2.9. Esquema conceptual de un repositorio

Un repositorio es la parte principal de un sistema de control de versiones. Son sistemas diseados para registrar, guardar y gestionar todos los cambios e informaciones sobre todos los datos de un proyecto a lo largo del tiempo.

Gracias a la informacin registrada en el repositorio se podr:

Consultar la ltima versin de los archivos que se hayan almacenado.

Acceder en la versin de un determinado da y compararla con la actual.

Consultar quin ha modificado un determinado trozo de cdigo y cuando fue modificado.

2.5.1 Problemticas de los sistemas de control de versiones

Los sistemas de control de versiones tienen que resolver ciertas problemticas, como por ejemplo, cmo evitar que las acciones de un programador se sobrepongan a las de otros programadores.

Contamos con diferentes alternativas para resolver estas problemticas:

Compartir archivos por parte de diferentes programadores

Bloquear los archivos utilizados

Fusionar los archivos modificados

Compartir archivos por parte de diferentes programadores

Dos compaeros que trabajan en el mismo proyecto, desarrollando una aplicacin informtica, deciden editar el mismo fichero del repositorio a la vez. Por ejemplo:

Pau y Montse estn editando un mismo fichero. Pablo graba sus cambios en el repositorio.

Como Pablo y Montse han accedido a la vez, la versin sobre la que Montse trabaja no contendr los cambios efectuados por Pablo. Montse podr, accidentalmente, sobreescribirlos con su nueva versin del archivo, por ser la ltima persona que los guarda. Los cambios de'n Pau no se encuentran en la nueva versin de Montse. La versin del archivo de'n Pau no se ha perdido para siempre (porque el sistema recuerda cada cambio).

 El resto de programadores que accedan al repositorio vern la nueva versin de Montse, pero no podrn ver los cambios de'n Pau a no ser que indaguen en el histrico del archivo.

En la figura 02:10 se puede observar esta secuencia de pasos que se pueden dar. El trabajo de'n Pau se obviado, lo que se debe evitar que se produzca. Por ello existen diversas soluciones que ofrecen las herramientas de control de versiones. Figura 2.1o. Caso de acceso a la vez en el mismo archivo por parte de dos usuarios

Bloquear los archivos utilizados

El caso expuesto anteriormente se puede prevenir utilizando alguna de las tcnicas que ofrecen las herramientas de control de versiones. Muchos de estos sistemas utilizan un modelo de solucin que consiste en bloquear los archivos afectados cuando un usuario est accediendo en modo modificacin. La secuencia sera:

Bloquear el archivo al que se desea acceder. Modificar el archivo por parte del usuario. Desbloquear el archivo una vez modificado y actualizado en el repositorio.

Se trata de una solucin sencilla tanto conceptualmente como de implementacin. Pero tiene algunos puntos no tan positivos. En primer lugar, slo permite acceder a la modificacin de un archivo a un nico usuario. En el caso planteado, Pau podr acceder al archivo para consultar y modificar, pero Montse no podr acceder, ya que Pablo lo tendr bloqueado. Habr que esperar que Pablo termine de modificar para desbloquearlo y, entonces, podr acceder ella. Se

trata de una solucin muy restrictiva que puede afectar negativamente el trabajo de los desarrolladores. En la figura 02:11 se pueden ver estos procedimientos.

Figura 2.11. Bloquear los archivos utilizados

Algunos problemas de esta solucin de bloqueo de archivos son:

Posible creacin de inconsistencias. Puede parecer que utilizando el sistema de los bloqueos haya ms seguridad a la hora de manipular archivos, pero puede darse el caso contrario. Si Pablo bloquea y edita el archivo A, mientras Montse simultneamente bloquea y edita el archivo B, pero los cambios que hacen no tienen en cuenta los cambios del otro desarrollador, se puede dar una situacin en la que, al dejar de bloquear los archivos, los cambios hechos a cada uno sean semnticamente incompatibles. De repente, A y B ya no funcionan juntos. Mientras un usuario, por ejemplo en Pau, est bloqueando un archivo, el acceso por parte del resto de desarrolladores no es viable. Si Pau olvida desbloquear el archivo o demora durante un tiempo largo, el resto de compaeros con necesidad de acceder quedarn a la espera de poder continuar su trabajo, bloqueados por Pablo. Esto puede causar muchos problemas de tipo administrativo dentro del equipo de trabajo. A veces, las necesidades de acceso a un mismo archivo son independientes, es decir, se puede requerir el acceso a diferentes partes del cdigo. Pablo puede necesitar editar el inicio de un archivo y Montse simplemente quiere cambiar la parte final de este archivo. Estos cambios no se superponen en absoluto. Ellos podran fcilmente editar el fichero de forma simultnea, y no habra ningn problema siempre que se asumiera que los cambios se fusionan correctamente. En esta situacin no es necesario seguir una poltica de bloqueos.

Precisamente, este ltimo problema del sistema de bloqueos es lo que sugiere otra solucin para el acceso simultneo al repositorio.

Fusionar los archivos modificados

Un Otro sistema para solucionar la problemtica de acceso simultneo a un mismo archivo, como alternativa al sistema de bloqueo de archivos, es el que se describe a continuacin:

Cada uno de los desarrolladores que necesite editar un archivo efectuar una copia privada. Cada desarrollador editar su copia privada del archivo.

Finalmente, se fusionarn varias copias privadas del archivo modificado. Esta fusin ser automtica por parte del sistema, aunque, finalmente, los desarrolladores son los responsables de dar el visto bueno si la fusin es correcta.

Por entender bien este sistema se puede observar la figura 02:12, Donde hay una explicacin grfica, que se basa en el siguiente ejemplo:

Pau y Montse crean copias de trabajo del mismo proyecto, obtenido del repositorio. Los dos desarrolladores trabajan simultneamente efectuando cambios en el mismo archivo A en sus copias locales:

Montse es la primera en grabar sus cambios en el repositorio.

Cuando Pablo intenta guardar sus cambios, el repositorio le informa que su archivo A no est actualizado. Pablo puede solicitar al asistente que efecte una propuesta de superposicin de los cambios. Lo ms seguro es que las modificaciones efectuadas por Montse y para Pablo no se superpongan, por lo que una vez que ambos conjuntos de cambios se han integrado, se registra la nueva versin del archivo en el repositorio.

Figura 12.2. Ejemplo de solucin con fusin

Este sistema podr funcionar de forma sencilla si los cambios de cada uno de los dos desarrolladores no afectan el trabajo del otro. Pero qu sucede si los cambios del primer desarrollador actan exactamente en la misma lnea de cdigo fuente que los cambios del segundo? En este caso se podra crear un conflicto. Para evitar este conflicto, ser necesario que el sistema tenga mucho cuidado a la hora de fusionar los dos archivos. Una posible forma de actuar sera:

Cuando Pablo pide al asistente que fusione los ltimos cambios del repo-sitorio a su copia de trabajo, su copia del archivo A marca de alguna manera que est en un estado de conflicto.

Pablo ser capaz de ver dos conjuntos de cambios conflictivos y, manualmente, podr elegir entre los dos o modificar el cdigo para que tenga en cuenta los dos. Una vez resueltos los cambios que se superponan de forma manual, podr guardar de forma segura el archivo fusionado al repositorio.

Esta situacin debera darse pocas veces, ya que la mayora de los cambios concurrentes no se superponen en absoluto y los conflictos no son frecuentes. Adems, muchas veces el tiempo que lleva resolver conflictos es mucho menor que el tiempo perdido por un sistema bloqueante.

El sistema de fusin de archivos es el utilizado por algunas herramientas de control de versiones como, por ejemplo, CVS o Subversion.

De esta forma, concluimos que el punto fuerte de este sistema es que permite el trabajo en paralelo de ms de un desarrollador o miembro del equipo de trabajo del proyecto, y el punto dbil es que no puede ser utilizado para archivos no fusionables, como podran ser las imgenes grficas donde cada desarrollador modifica la imagen por otra. La buena ser o la primera o la segunda, pero no se podrn fusionar.

2.6

Comentarios y documentacin del software

Un complemento muy til para los desarrolladores es la documentacin del cdigo fuente que se est implementando. Existen muchas formas diferentes de documentar con muchos niveles diferentes de profundizacin. La opcin ms sencilla es la primera que se aprende cuando se empieza a programar, que son los comentarios a lo largo del cdigo fuente.

Documentar el cdigo de un programa es dotar al software de toda la informacin que sea necesaria para explicar lo que hace. Los desarrolladores que llevan a cabo el software (y el resto del equipo de trabajo) deben entender qu est haciendo el cdigo y el porqu.

Los comentarios se encuentran intercalados con las sentencias de programacin, de hecho se consideran parte del cdigo fuente. Son pequeas frases que explican pequeas partes de las sentencias de programacin implementadas.

Los comentarios no son tenidos en cuenta por parte de los compiladores a la hora de convertir el cdigo fuente en cdigo objeto y, posteriormente, en cdigo ejecutable. Esto da libertad al programador para poder escribir cualquier cosa en ese espacio que l habr indicado que es un comentario, sin tener que cumplir ninguna sintaxis especfica.

Existen diferentes formas implementar comentarios, ir en funcin del lenguaje de programacin que se utilice. A continuacin se muestra la forma de implementar comentarios con Java. Con este lenguaje hay dos formas de expresar comentarios, interna y externamente:

Comentarios internos: Igual que en el lenguaje de programacin C y otros derivados, la forma de mostrar comentarios intercalados con el cdigo fuente es aadiendo los caracteres . Esto indicar que a partir de ese punto todo lo que se escriba hasta el final de la lnea estar considerado como comentario y el compilador no lo tendr en cuenta. Otra forma de mostrar comentarios es aadiendo los caracteres ... , donde el comentario se encontrara ubicado en el lugar de los puntos suspensivos y, a diferencia de la anterior, se pueden escribir comentarios de ms de una lnea. A continuacin, se muestra un ejemplo de cmo se puede documentar un pequeo trozo de cdigo que contendr los tipos de comentarios trabajados. El cdigo est implementado en Javascript, ya que en un entorno web las validaciones se suelen hacer en la mquina cliente.

1/ * Funcin que efecta una validacin del DNI, retornando cierto si el DNI especificado tiene 8 caracteres y falso en caso contrario * / 2function validarDNI (DNI) { 3 4 5 6 7 8 9 10 11 } if (DNI.value! = "") { / / Valida que la variable DNI tenga algn valor. / / Valida la longitud del DNI.

if (DNI.value.length <8) {

alert ("El DNI no es correcto"); / / Muestra por pantalla un mensaje de error. DNI.focus (); return false; } } return true; / / La funcin devuelve un true indicando que el DNI es vlido. / / Posiciona el cursor a la variable DNI. / / La funcin devuelve un false indicando que el DNI no es vlido.

API Del ingls Application Programming Interface (Interfaz de programacin de aplicaciones). En la programacin orientada a objetos, las API ofrecen funciones y procedimientos para ser utilizados por otras aplicaciones.

Comentarios o documentacin a partir de la utilidad Javadoc: este tipo de utilidad de creacin de documentacin a partir de comentarios ha sido desarrollada por Oracle. Javadoc permite la creacin de documentacin de API en formato HTML. Actualmente, es el estndar para crear comentarios de clases desarrolladas en Java. La sintaxis utilizada para este tipo de comentarios es empezar por y finalizar con , donde se incorporar el carcter para cada lnea, tal como se muestra a continuacin:

1/ ** Comentario de Javadoc 2*De forma automtica se generar una pgina HTML con las comentarios especificados en el cdigo. 3*@ Etiqueta1 texto especfico del etiqueta1 4*@ Etiqueta2 texto especfico del etiqueta2 5*/

La diferencia entre este tipo de comentarios y los comentarios internos es que los comentarios Javadoc s tienen una estructura especfica que hay que seguir para ser escritos. En cambio, los comentarios internos dan completa libertad para ser implementados. Otra diferencia significativa es el objetivo de los comentarios. Los comentarios internos se hacen servir todo el cdigo fuente, mientras que los comentarios Javadoc estn pensados para ser utilizados al principio de cada clase y de cada mtodo. Finalmente, los comentarios Javadoc generan de forma automtica la documentacin tcnica del software, en formato HTML.

2.6.1

Estructura de los comentarios tipo Javadoc

Los comentarios tipo Javadoc siguen unos estndares en su creacin:

Lo primero que hay que indicar es la descripcin principal del comentario. Esta descripcin es lo que se puede encontrar desde la indicacin de comienzo del comentario con los caracteres hasta que se llega a la seccin donde se encuentran las etiquetas, que se indican con el carcter . La descripcin general es un espacio donde se podr escribir lo que se querr, con la longitud que se crea conveniente, es el ms cercano a los comentarios estndares.

A continuacin de la descripcin principal, se encuentra una zona de etiquetas (tags) Que empiezan por el carcter . Las etiquetas son case-sensitive, Que quiere dijo que su significado cambiar si su nombre se escribe en minsculas o en maysculas. Una vez ha comenzado la seccin de etiquetas, no se podr continuar con la descripcin general del comentario Javadoc. Las etiquetas se deben encontrar siempre al principio de las lneas, con su identificador, el carcter . Como mucho se podr dejar un espacio y un asterisco antes de la etiqueta. Si no se sigue esta nomenclatura, la etiqueta ser tratada como un texto descriptivo.

Algunas de las etiquetas son:

t r . Especifica el autor del cdigo, en el caso de que haya sido escrito por varios autores, se podr replicar la etiqueta tantas veces como autores haya o escribir con una nica etiqueta con los diferentes nombres de los autores separados por una coma.

rs rs . Especifica la versin del cdigo.

r estar tr s r . Por cada uno de los parmetros de entrada, se aade el parmetro y su descripcin. r t r s r . Indica el tipo de valor que devolver la funcin. t s r . Agregar una entrada "Throws", que contiene el nombre de la excepcin que puede ser lanzada por el mtodo. s r r .Asocia con otro mtodo o clase.

r t t r . Informa, en forma de advertencia, que una determinada funcionalidad no debera utilizarse porque ha quedado obsoleta. Los comentarios Javadoc pueden aadir cdigo HTML en su descripcin, lo que permitir poder dar formato a los comentarios escritos. Si, por ejemplo, se quisiera subrayar una parte de la descripcin principal, slo habra que utilizar la etiqueta y antes y despus del fragmento de comentario a subrayar. Esto permitir dar un nfasis especial a determinados comentarios. Por ejemplo:

1/ ** 2*Ejemplo de descripcin general de un comentario <u> Javadoc. </ U> 3@ Author Programador primero del proyecto 4*/

Con Java se puede declarar ms de un atributo en una misma sentencia. Si se quiere comentar esta sentencia para indicar a qu corresponde cada atributo, se necesitar ms de una lnea de comentarios. Por esta razn, si se quiere tener comentada la declaracin de atributos, uno a uno, ser necesario utilizar una lnea de cdigo para cada declaracin.

No es lo mismo los comentarios del cdigo fuente que la documentacin del software. Los comentarios son una forma de documentar, dar informacin referente al cdigo fuente, pero

estn integrados en el mismo cdigo. Lo que se conoce como la documentacin del software es la creacin de documentos externos al cdigo (archivos), como pueden ser manuales tcnicos o manuales de usuario. Estos documentos externos debern ser mucho ms explicativos y, a la vez, ms fciles de comprender que los comentarios del cdigo.

Un usuario tendr acceso a los manuales funcionales o de usuario, pero nunca acceder al cdigo fuente, as que no podr ver los comentarios del cdigo intercalados en el software. Un programador que tenga que hacer el mantenimiento o tenga que ampliar la aplicacin informtica, adems de tener acceso a la documentacin tcnica y funcional, s podr acceder a estos comentarios del cdigo fuente.

2.6.2

Ejemplo de comentarios tipo Javadoc

En el siguiente ejemplo se efecta una propuesta de los comentarios tipo Javadoc para la clase factorial, clase que calcula el factorial de un nmero.

1/ ** 2 3 4 5 *Clase que calcula el factorial de un nmero. *@ Author IOC *@ Version 2012 */

6public class Factorial { 7 8 9 10 / ** *Calcula el factorial de n. *n! = N * (n-1) *(N-2) *(N-3) *... *1

11 12 13 14 15 16 17 18 19 20 21 22 23 24 }

*@ Param n es el nmero al que se calcular el factorial. *@ Return n! es el resultado del factorial de n */ public static double factorial (double n) {

if (n == 0) return 1; else { double resultado = N * factorial (n-1); return resultado; } }

2.6.3

Ejemplo de utilizacin de Javadoc con Eclipse

Muchas de las herramientas integradas de desarrollo de software que permiten programar en Java ofrecen funcionalidades para poder crear documentacin a partir de Javadoc. Eclipse no es una excepcin y tambin ofrece esta posibilidad.

Una vez desarrollado un proyecto en Java y aadidos los comentarios con las estructuras y estndares Javadoc, se podr generar la documentacin de forma automtica utilizando la

funcionalidad Generar Javadoc del men Proyecto,como se puede ver en la figura 02:13. Esta utilidad es parte del Java Development Kit. Figura 2.13. Men 'Proyecto' - 'Generar Javadoc'

A continuacin, obtendr un dilogo que pedir la ubicacin del archivo Javadoc.Exe y una serie de opciones de la creacin de la documentacin, como la carpeta destino de los archivos que se crearn o el tipo de clases de las cuales se de crear la documentacin. Este dilogo se puede observar en la figura 02:14. Figura 2.14. Dilogo para la creacin de la documentacin a partir de Javadoc

JDK, Java Development Kit, es un software que aporta herramientas de desarrollo para la creacin de software en Java.

Al hacer clic sobre el botn Finalizar,automticamente se ha generado la documentacin en formato HTML, como se puede observar en la figura 02:15. Figura 15.2. Documentacin generada por Javadoc

Si abrimos en el navegador el archivo index.html, se puede ver el documento generado. Esta documentacin generada se puede observar en las figuras 35 y 36. Figura 16.2. Documentacin generada por Javadoc

Javadoc se puede encontrar en las versiones de Eclipse para los diferentes sistemas operativos (Windows, Linux y MacOS).

A la figura 02:16 se puede observar la descripcin general de toda la clase, junto con su estructura. Tambin se puede observar el resumen de su constructor y sus mtodos.

En la figura 02:17 se puede observar el detalle del constructor y el detalle de los mtodos, con la informacin que se ha ido introduciendo como comentarios a lo largo del cdigo fuente.

Figura 17.2. Ampliacin de la documentacin generada