ED04_Contenidos

1 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

Optimizacin y documentacin.
Caso prctico
Situacin
BK programacin se encuentra desarrollando la aplicacin de gestin
hotelera.
Como parte del proceso de desarrollo surgen una serie de problemas:
hay un cdigo que presenta algunas implementaciones que se pueden
mejorar aplicando refactorizacin, nos encontramos que los miembros
del equipo de desarrollo estn modificando constantemente mtodos o
clases, creando diferentes versiones de las mismas y falta una
documentacin clara y precisa del cdigo.
Ada propone a Juan y a Mara (programadores principales de la
aplicacin) que usen los patrones generales de refactorizacin para
conseguir un cdigo de mejor calidad, ms fcil de entender, ms fcil de probar y con menor
probabilidad de generar errores. Ana va a intentar ayudar a Juan, y Carlos a Mara, pero no
conocen nada de refactorizacin, ni entiende la necesidad de realizar este trabajo "extra".
Como todos los miembros de BK Programacin trabajan sobre los mismo proyectos, Ada debe
coordinar el trabajo de todos ellos, por lo que propone que cada uno de ellos utilice un cliente de
control de versiones, de forma que ella, de manera centralizada, pueda gestionar la
configuracin del software.
Los miembros con menor experiencia, Carlos y Ana, van a ir generando, utilizando herramientas
de documentacin automatizadas, la documentacin de las clases y del cdigo generado por
Juan y Mara.
Ada va a encargarse de la Gestin de Configuraciones del Software, ya que es una labor
fundamental para cualquier jefe de proyecto. Asimismo, debe garantizar que el cdigo generado
por Juan y Mara est refactorizado.

29/06/2013 13:49

ED04_Contenidos

2 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

1.- Refactorizacin.

Caso prctico
Gran parte de las clases, mtodos y mdulos que forman
parte de la aplicacin de Gestin Hotelera han sido
implementados, surge ahora una pregunta. Podemos
mejorar la estructura del cdigo y que sea de mayor calidad,
sin que cambie su comportamiento? Cmo hacerlo? Qu
patrones hay que seguir?

La refactorizacin es una disciplina tcnica, que consiste en

realizar pequeas transformaciones en el cdigo de un programa,
para mejorar la estructura sin que cambie el comportamiento ni
funcionalidad del mismo. Su objetivo es mejorar la estructura
interna del cdigo. Es una tarea que pretender limpiar el cdigo
minimizando la posibilidad de introducir errores.
Con la refactorizacin se mejora el diseo del software, hace que
el software sea ms fcil de entender, hace que el mantenimiento
del software sea ms sencillo, la refactorizacin nos ayuda a
encontrar errores y a que nuestro programa sea ms rpido.
Cuando se refactoriza se est mejorando el diseo del cdigo despus de haberlo escrito. Podemos partir
de un mal diseo y, aplicando la refactorizacin, llegaremos a un cdigo bien diseado. Cada paso es
simple, por ejemplo mover una propiedad desde una clase a otra, convertir determinado cdigo en un nuevo
mtodo, etc. La acumulacin de todos estos pequeos cambios pueden mejorar de forma ostensible el
diseo.

Para saber ms
Puedes visitar la siguiente pgina web (en ingls), donde se presenta el proceso de
refactorizacin de aplicaciones Java con Netbeans.
Refactorizacin en Netbeans.

29/06/2013 13:49

ED04_Contenidos

3 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

1.1.- Concepto.

Caso prctico
Juan va a empezar a refactorizar parte del cdigo que ha
generado. Ana no sabe que es refactorizar, as que Juan le
va a explicar las bases del proceso de refactorizacin.

El concepto de refactorizacin de cdigo, se base en el concepto

matemtico de factorizacin de polinomios.
Podemos definir el concepto de refactorizacin de dos formas:
Refactorizacin: Cambio hecho en la estructura interna del software para hacerlo ms fcil de
entender y fcil de modificar sin modificar su comportamiento.
Ejemplos de refactorizacin es "Extraer Mtodo" y "Encapsular Campos". La refactorizacin es
normalmente un cambio pequeo en el software que mejora su mantenimiento.
Campos encapsulados: Se aconseja crear mtodos getter y setter, (de asignacin y de consulta)
para cada campo que se defina en una clase. Cuando sea necesario acceder o modificar el valor de
un campo, basta con invocar al mtodo getter o setter segn convenga.
Refactorizar: Reestructurar el software aplicando una serie de refactorizaciones sin cambiar su
comportamiento.
El propsito de la refactorizacin es hacer el software ms fcil de entender y de modificar. Se pueden
hacer muchos cambios en el software que pueden hacer algn pequeo cambio en el comportamiento
observable. Solo los cambios hechos para hacer el software ms fcil de entender son refactorizaciones.
Hay que diferenciar la refactorizacn de la optimizacin. En ambos procesos, se pretende mejorar la
estructura interna de una aplicacin o componente, sin modificar su comportamiento. Sin embargo, cuando
se optimiza, se persigue una mejora del rendimiento, por ejemplo mejorar la velocidad de ejecucin, pero
esto puede hacer un cdigo ms difcil de entender.
Hay que resaltar que la refactorizacin no cambia el comportamiento observable del software. El software
sigue cumpliendo la misma funcin que hacia antes. Ningn usuario, ya sea usuario final u otro
programador, podr determinar que cosas han cambiado.

Reflexiona
Con la refactorizacin de cdigo, estamos modificando un cdigo que funciona correctamente,
merece la pena el esfuerzo de refactorizar un cdigo ya implementado?
Merece la pena, por que el cdigo que se consigue suele ser ms fcil de entender por otros
programadores y programadoras, y por tanto, ms fcil de mantener. Adems, en muchos
casos, se mejora la eficiencia del programa.

29/06/2013 13:49

ED04_Contenidos

4 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

1.2.- Limitaciones.

Caso prctico
Ana se muestra muy interesada por conocer esta tcnicas
avanzadas se programacin, sin embargo Juan le pone los
pies en el suelo, explicndole que son tcnicas con muchas
limitaciones y poca documentacin en la que basarse.

La refactorizacin es un tcnica lo suficientemente novedosa para conocer cules son los beneficios que
aporta, pero falta experiencia para conocer el alcance total de sus limitaciones. Se ha constatado que la
refactorizacin presente problemas en algunos aspectos del desarrollo.
Un rea problemtica de la refactorizacin son las bases de datos. Una base de datos presenta muchas
dificultades para poder ser modificada, dado la gran cantidad de interdependencias que soporta. Cualquier
modificacin que se requiera de las bases de datos, incluyendo modificacin de esquema y migracin de
datos, puede ser una tarea muy costosa. Es por ello que la refactorizacin de una aplicacin asociada a una
base de datos, siempre ser limitada, ya que la aplicacin depender del diseo de la base de datos.
interfaces. Cuando refactorizamos, estamos modificando la
Otra limitacin, es cuando cambiamos
estructura interna de un programa o de un mtodo. El cambio interno no afecta al comportamiento ni a la
interfaz. Sin embargo, si renombramos un mtodo, hay que cambiar todas las referencias que se hacen a
l. Siempre que se hace esto se genera un problema si es una interfaz pblica. Una solucin es mantener
las dos interfaces, la nueva y la vieja, ya que si es utilizada por otro clase o parte del proyecto, no podr
referenciarla.
Hay determinados cambios en el diseo que son difciles de refactorizar. Es muy difcil refactorizar cuando
hay un error de diseo o no es recomendable refactorizar, cuando la estructura a modificar es de vital
importancia en el diseo de la aplicacin.
Hay ocasiones en las que no debera refactorizar en absoluto. Nos podemos encontrar con un cdigo que,
aunque se puede refactorizar, sera ms fcil reescribirlo desde el principio. Si un cdigo no funciona, no se
refactoriza, se reescribe.

Autoevaluacin
La refactorizacin:
Se utiliza como tcnica complementaria de realizacin de pruebas.
Genera un cdigo ms difcil de entender y de mantener.
Utiliza una serie de patrones, de aplicacin sobre el cdigo fuente.
Es una tcnica de programacin no recogida por los entornos de desarrollo.
Muy bien. Esa es la idea.

29/06/2013 13:49

ED04_Contenidos

5 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

1.3.- Patrones de refactorizacin ms habituales.

Caso prctico
A pesar de la poca documentacin y lo novedoso de la
tcnica, Juan le ensea a Ana algunos de los patrones ms
habituales de refactorizacin, que vienen ya integrados en la
mayora de los entornos de desarrollos ms extendidos en el
mercado.

En el proceso de refactorizacin, se siguen una serie de patrones

preestablecidos, los ms comunes son los siguientes:
Renombrado (rename): este patrn nos indica que debemos
cambiar el nombre de un paquete, clase, mtodo o campo,
por un nombre ms significativo.
Sustituir bloques de cdigo por un mtodo: este patrn
nos aconseja sustituir un bloque de cdigo, por un mtodo.
De esta forma, cada vez que queramos acceder a ese
bloque de cdigo, bastara con invocar al mtodo.
Campos encapsulados: se aconseja crear mtodos getter y setter, (de asignacin y de consulta)
para cada campo que se defina en una clase. Cuando sea necesario acceder o modificar el valor de
un campo, basta con invocar al mtodo getter o setter segn convenga.
Mover la clase: si es necesario, se puede mover una clase de un paquete a otro, o de un proyecto a
otro. La idea es no duplicar cdigo que ya se haya generado. Esto impone la actualizacin en todo el
cdigo fuente de las referencias a la clase en su nueva localizacin.
Borrado seguro: se debe comprobar, que cundo un elemento del cdigo ya no es necesario, se
han borrado todas la referencias a l que haba en cualquier parte del proyecto.
Cambiar los parmetros del proyecto: nos permite aadir nuevos parmetros a un mtodo y
cambiar los modificadores de acceso.
Extraer la interfaz: crea un nueva interfaz de los mtodos public non-static seleccionados en una
clase o interfaz.
Mover del interior a otro nivel: consiste en mover una clase interna a un nivel superior en la
jerarqua.

29/06/2013 13:49

ED04_Contenidos

6 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

1.4.- Analizadores de cdigo.

Caso prctico
Mara se va a centrar el el uso de analizadores de cdigo con
la ayuda de Carlos. Carlos no sabe lo que son los
analizadores de cdigo ni para qu sirven.

Cada IDE incluye herramientas de refactorizacin y analizadores de cdigo. En el caso se

software libre, existen analizadores de cdigo que se pueden aadir como complementos
a los entornos de desarrollo. Respecto a la refactorizacin, los IDE ofrecen asistentes que
de forma automtica y sencilla, ayudan a refactorizar el cdigo.

El anlisis esttico de cdigo, es un proceso que tiene como objetivo, evaluar el software, sin llegar a
ejecutarlo. Esta tcnica se va a aplicar directamente sobre el cdigo fuente, para poder obtener informacin
que nos permita mejorar la base de cdigo, pero sin que se modifique la semntica.
Los analizadores de cdigo, son las herramientas encargadas de realizar esta labor. El analizador esttico
de cdigo recibir el cdigo fuente de nuestro programa, lo procesar intentando averiguar la funcionalidad
del mismo, y nos dar sugerencias, o nos mostrar posibles mejoras.
Los analizadores de cdigo incluyen analizadores lxicos y sintcticos que procesan el cdigo fuente y de
un conjunto de reglas que se deben aplicar sobre determinadas estructuras. Si el analizador considera que
nuestro cdigo fuente tiene una estructura mejorable, nos lo indicar y tambin nos comunicar la mejora a
realizar.
Las principales funciones de los analizadores es encontrar partes del cdigo que puedan reducir el
rendimiento, provocar errores en el software, tener una excesiva complejidad, complicar el flujo de datos,
crear problemas de seguridad.
El anlisis puede ser automtico o manual. El automtico, los va a realizar un programa, que puede formar
parte de la funcionalidad de un entorno de desarrollo, por ejemplo el FindBugs en Netbeans, o manual,
cuando es una persona.
El anlisis automtico reduce la complejidad para detectar problemas de base en el cdigo, ya que los
busca siguiendo una serie de reglas predefinidas. El anlisis manual, se centra en apartados de nuestra
propia aplicacin, como comprobar que la arquitectura de nuestro software es correcta.
Tomando como base el lenguaje de programacin Java, nos encontramos en el mercado un conjunto de
analizadores disponibles:
PMD. Esta herramienta basa su funcionamiento en detectar patrones, que son posibles errores en tiempo
de ejecucin, cdigo que no se puede ejecutar nunca porque no se puede llegar a l, cdigo que puede ser
optimizado, expresiones lgicas que pueden ser simplificadas, malos usos del lenguaje, etc.
CPD. Forma parte del PMD. Su funcin es encontrar cdigo duplicado.

29/06/2013 13:49

ED04_Contenidos

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

1.4.1.- Uso.
Los analizadores de cdigo esttico, se suelen integrar en los Entornos de Desarrollo, aunque en algunos
casos, hay que instalarlos como
plug-in, tras instalar el IDE. En el caso de Netbeans 6.9.1, vamos a
instalar el plug-in para PMD. Para ello lo descargamos de sourceforge. Se descomprime el plug-in para
Netbeans y se aade a los complementos de nuestro entorno de desarrollo. Para ello podemos utilizar el
siguiente enlace:
Descarga de PMD.

Como se indic en el apartado anterior, PMD es un analizador de cdigo esttico, capaz de detectar
automticamente un amplio rango de defectos y de inseguridades en el cdigo. PMD se centra en detectar
defectos de forma preventiva.
Una vez que tenemos desarrollado nuestro cdigo, si queremos analizarlo con PMD, y obtener el informe
del anlisis, pulsamos el botn derecho del ratn sobre el directorio que contiene los ficheros de cdigo, en
la vista de proyectos y elegimos: Herramientas - Ejecutar PMD.
Mientras se analiza el cdigo, el plug-in mostrar una barra de progreso en la esquina inferior derecha. El
informe producido contiene la localizacin, el nombre de la regla que no se cumple y la recomendacin de
cmo se resuelve el problema.
El informe PMD, nos permite navegar por el fichero de clases y en la lnea donde se ha detectado el
problema. En el nmero de lnea, veremos una marca PMD. Si se posiciona el ratn encima de ella,
veremos un tooltip con la descripcin del error.

7 de 36

29/06/2013 13:49

ED04_Contenidos

8 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

1.4.2.- Configuracin.
La configuracin de los analizadores de cdigo, nos va a permitir definir nuestras propias reglas,
aadindolas a las que el analizador nos proporciona por defecto.
En el caso del analizador de cdigo PMD, lo primero que vamos a hacer, es conocer las reglas que son
aplicables. Elegimos las reglas que son aplicables accediendo a Herramientas - Opciones - Varios - PMD
Enable Scan habilita el escaneado automtico del proyecto, a intervalos regulares. Si pulsamos en Manage
Rules nos iremos a un cuadro de dilogo que nos permitir activar o desactivar reglas especficas.
Si seleccionamos el nombre de una regla, podemos ver una descripcin del problema y un ejemplo de
aplicacin.
Si lo que queremos es introducir nuestras propias reglas, hacemos clic sobre Manage Rulesets. Se
nos mostrar una nuevo formulario donde podemos importar un fichero
XML o
JAR con reglas.
Para crear ficheros XML con conjuntos de reglas, podemos obtener informacin en la siguiente pgina web.
Creacin de reglas para PMD, en ingls.

29/06/2013 13:49

ED04_Contenidos

9 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

1.5.- Refactorizacin y pruebas.

Caso prctico
Juan ayudado por Ana, se ha dedicado a refactorizar
algunas partes del cdigo que haba diseado. Al modificar
el cdigo diseado, se encuentra en al necesidad de realizar
pruebas de nuevo.

En la actualidad, la refactorizacin y las pruebas, son dos

aspectos del desarrollo de aplicaciones, que por sus implicaciones
y su interrelacin, se han convertido en conceptos de gran
importancia para la industria. Muchas cuestiones y problemas
siguen sin ser explorados en estos dos mbitos. Uno de los
enfoques actuales, que pretende integrar las pruebas y la
refactorizacin, es el Desarrollo Guiado por Pruebas (TDD, Test
Driven Development).
Con el Desarrollo Guiado por Pruebas (TDD), se propone agilizar
el ciclo de escritura de cdigo, y realizacin de pruebas de unidad.
Cabe recordar, que el objetivo de las pruebas de unidad, es
comprobar la calidad de un mdulo desarrollado. Existen
utilidades que permiten realizar esta labor, pudiendo ser personas distintas a las que los programan,
quienes los realicen. Esto provoca cierta competencia entre los programadores de la unidad, y quienes
tienen que realizar la prueba. El proceso de prueba, supone siempre un gasto de tiempo importante, ya que
el programador realiza revisiones y depuraciones del mismo antes de enviarlo a prueba. Durante el proceso
de pruebas hay que disear los casos de prueba y comprobar que la unidad realiza correctamente su
funcin. Si se encuentran errores, stos se documentan, y son enviados al programador para que lo
subsane, con lo que debe volver a sumergirse en un cdigo que ya haba abandonado.
Con el Desarrollo Guiado por Pruebas, la propuesta que se hace es totalmente diferente. El programador
realiza las pruebas de unidad en su propio cdigo, e implementa esas pruebas antes de escribir el cdigo a
ser probado.
Cuando un programador recibe el requerimiento para implementar una parte del sistema, empieza por
pensar el tipo de pruebas que va a tener que pasar la unidad que debe elaborar, para que sea correcta.
Cuando ya tiene claro la prueba que debe de pasar, pasa a programar las pruebas que debe pasar el
cdigo que debe de programar, no la unidad en s. Cuando se han implementado las pruebas, se comienza
a implementar la unidad, con el objeto de poder pasar las pruebas que dise previamente.
Cuando el programador empieza a desarrollar el cdigo que se le ha encomendado, va elaborando
pequeas versiones que puedan ser compiladas y pasen por alguna de las pruebas. Cuando se hace un
cambio y vuelve a compilar tambin ejecuta las pruebas de unidad. Y trata de que su programa vaya
pasando ms y ms pruebas hasta que no falle en ninguna, que es cuando lo considera listo para ser
integrado con el resto del sistema.
Para realizar la refactorizacin siguiendo TDD, se refactoriza el cdigo tan pronto como pasa las pruebas
para eliminar la redundancia y hacerlo ms claro. Existe el riesgo de que se cometan errores durante la
tarea de refactorizacin, que se traduzcan en cambios de funcionalidad y, en definitiva, en que la unidad
deje de pasar las pruebas. Tratndose de reescrituras puramente sintcticas, no es necesario correr ese
riesgo: las decisiones deben ser tomadas por un humano, pero los detalles pueden quedar a cargo de un
programa que los trate automticamente.

29/06/2013 13:49

ED04_Contenidos

10 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

1.6.- Herramientas de ayuda a la refactorizacin.

Caso prctico
Ana ya conoce los principios y patrones bsico de
refactorizacin, ahora Juan le va a ensear las herramientas
de Netbeans para refactorizar de forma automtica y
sencilla, cdigo Java.

Los entornos de desarrollo actuales, nos proveen de una serie de

herramientas que nos facilitan la labor de refactorizar nuestro
cdigo. En puntos anteriores, hemos indicado algunos de los
patrones que se utilizan para refactorizar el cdigo. Esta labor se
puede realizar de forma manual, pero supone una prdida de
tiempo, y podemos inducir a redundancias o a errores en el cdigo
que modificamos.
En el Entorno de Desarrollo Netbeans, la refactorizacin est
integrada como una funcin ms, de las utilidades que incorpora.
A continuacin, vamos a usar los patrones ms comunes de refactorizacin, usando las herramientas de
ayuda del entorno.
Renombrar. Ya hemos indicado en puntos anteriores, que podemos cambiar el nombre de un
paquete, clase, mtodo o campo para darle un nombre ms significativo. Netbeans nos permite
hacerlo, de forma que actualizar todo el cdigo fuente de nuestro proyecto donde se haga
referencia al nombre modificado.
Introducir mtodo. Con este patrn podemos seleccionar un conjunto de cdigo, y reemplazarlo por
un mtodo.
Encapsular campos. Netbeans puede automticamente generar mtodos getter y setter para un
campo, y opcionalmente actualizar todas las referencias al cdigo para acceder al campo, usando los
mtodos getter y setter.

Autoevaluacin
Cul no es un patrn de refactorizacin?
Eliminar parmetros de un mtodo.
Renombrado.
Sustitucin de un bloque de sentencias por un mtodo.
Mover clase.
Correcta. Al eliminar parmetros de un mtodo, podra cambiar el comportamiento del
mtodo.

29/06/2013 13:49

ED04_Contenidos

11 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

2.- Control de versiones.

Caso prctico
Juan y Mara estn implementando la mayor parte de la
aplicacin. Continuamente est modificando el cdigo
generado, bien para mejorar algunos aspecto, o por qu han
refactorizado. Hay diferentes versiones de una misma clase,
de un mismo mtodo. Qu ocurre si se borra
accidentalmente algn fichero? Qu pasa si Mara modifica
una clase que necesita Juan?

Con el trmino versin, se hace referencia a la evolucin de un

nico elemento, o de cada elemento por separado, dentro de un
sistema en desarrollo.
Siempre que se est realizando una labor, sea del tipo que sea, es
importante saber en cada momento de que estamos tratando, qu
hemos realizado y qu nos queda por realizar. En el caso del
desarrollo de software ocurre exactamente lo mismo. Cuando
estamos desarrollando software, el cdigo fuente est cambiando
continuamente, siendo esta particularidad vital. Esto hace que en
el desarrollo de software actual, sea de vital importancia que haya
sistemas de control de versiones. Las ventajas de utilizar un sistema de control de versiones son mltiples.
Un sistema de control de versiones bien diseado facilita al equipo de desarrollo su labor, permitiendo que
varios desarrolladores trabajen en el mismo proyecto (incluso sobre los mismo archivos) de forma
simultnea, sin que se que pisen unos a otros. Las herramientas de control de versiones proveen de un sitio
central donde almacenar el cdigo fuente de la aplicacin, as como el historial de cambios realizados a lo
largo de la vida del proyecto. Tambin permite a los desarrolladores volver a un versin estable previa del
cdigo fuente si es necesario.
Una versin, desde el punto de vista de la evolucin, se define como la forma particular de un objeto en un
instante o contexto dado. Se denomina revisin, cuando se refiere a la evolucin en el tiempo. Pueden
coexistir varias versiones alternativas en un instante dado y hay que disponer de un mtodo, para designar
las diferentes versiones de manera sistemtica u organizada.
En los entornos de desarrollo modernos, los sistemas de control de versiones son una parte fundamental,
que van a permitir construir tcnicas ms sofisticadas como la Integracin Continua.
En los proyectos Java, existen dos sistemas de control de versiones de cdigo abierto, CVS y Subversion.
La herramienta CVS es una herramienta de cdigo abierto que es usada por gran cantidad de
organizaciones. Subversion es el sucesor natural de CVS, ya que se adapta mejor que CVS a las modernas
prcticas de desarrollo de software.

Para gestionar las distintas versiones que se van generando durante el desarrollo de una
aplicacin, los IDE, proporcionan herramientas de Control de Versiones y facilitan el
desarrollo en equipo de aplicaciones.

29/06/2013 13:49

ED04_Contenidos

12 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

2.1.- Estructura de herramientas de control de versiones.

Caso prctico
Para Ana el concepto de control de versiones le resulta muy
abstracto. Juan va a intentar explicarle como funciona el
mecanismo de control de versiones, tomando como ejemplo
una herramienta que l conoce: CVS.

Las herramientas de control de versiones, suelen estar formadas

por un conjunto de elementos, sobre los cuales, se pueden
ejecutar rdenes e intercambiar datos entre ellos. Como ejemplo,
vamos a analizar ha herramienta CVS.
Una herramienta de control de versiones, como CVS, es un
sistema de mantenimiento de cdigo fuente (grupos de archivos
en
general)
extraordinariamente
til
para
grupos
de
desarrolladores que trabajan cooperativamente usando alguna
clase de red. CVS permite a un grupo de desarrolladores trabajar
y modificar concurrentemente ficheros organizados en proyectos. Esto significa que dos o ms personas
pueden modificar un mismo fichero sin que se pierdan los trabajos de ninguna. Adems, las operaciones
ms habituales son muy sencillas de usar.
CVS utiliza una arquitectura cliente-servidor: un servidor guarda la versin actual del proyecto y su historia,
y los clientes conectan al servidor para sacar una copia completa del proyecto, trabajar en esa copia y
entonces ingresar sus cambios. Tpicamente, cliente y servidor conectan utilizando Internet, pero cliente y
servidor pueden estar en la misma mquina. El servidor normalmente utiliza un sistema operativo similar a
Unix, mientras que los clientes CVS pueden funcionar en cualquier de los sistemas operativos ms
difundidos.
Los clientes pueden tambin comparar diferentes versiones de ficheros, solicitar una historia completa de
los cambios, o sacar una "foto" histrica del proyecto tal como se encontraba en una fecha determinada o
en un nmero de revisin determinado. Muchos proyectos de cdigo abierto permiten el "acceso de lectura
annimo", significando que los clientes pueden sacar y comparar versiones sin necesidad de teclear una
contrasea; solamente el ingreso de cambios requiere una contrasea en estos escenarios. Los clientes
tambin pueden utilizar el comando de actualizacin con el fin de tener sus copias al da con la ltima
versin que se encuentra en el servidor. Esto elimina la necesidad de repetir las descargas del proyecto
completo.
El sistema de control de versiones est formado por un conjunto de componentes:
Repositorio: es el lugar de almacenamiento de los datos de los proyectos. Suele ser un directorio en
algn ordenador.
Mdulo: en un directorio especifico del repositorio. Puede identificar una parte del proyecto o ser el
proyecto por completo.
Revisin: es cada una de las versiones parciales o cambios en los archivos o repositorio completo.
La evolucin del sistema se mide en revisiones. Cada cambio se considera incremental.
Etiqueta: informacin textual que se aada a un conjunto de archivos o a un mdulo completo para
indicar alguna informacin importante.
Rama: revisiones paralelas de un mdulo para efectuar cambios sin tocar la evolucin principal. Se
suele emplear para pruebas o para mantener los cambios en versiones antiguas.
Las rdenes que se pueden ejecutar son:
checkout: obtiene un copia del trabajo para poder trabajar con ella.

29/06/2013 13:49

ED04_Contenidos

13 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

Update: actualiza la copia con cambios recientes en el repositorio.

Commit: almacena la copia modificada en el repositorio.
Abort: abandona los cambios en la copia de trabajo.

29/06/2013 13:49

ED04_Contenidos

14 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

2.2.- Repositorio.

Caso prctico
Juan le ha explicado a Ana la los fundamentos del control de
versiones, pero quiere profundizar ms en el concepto de
repositorio, ya que para l es la parte fundamental del
control de versiones.

El repositorio es la parte fundamental de un sistema de control de versiones. Almacena

toda la informacin y datos de un proyecto.

El repositorio es un almacn general de versiones. En la mayora de las herramientas de control de

versiones, suele ser un directorio.
El repositorio centraliza todos los componentes de un mismo sistema, incluyendo las distintas versiones de
cada componente. Con el repositorio, se va a conseguir un ahorro de espacio de almacenamiento, ya que
estamos evitando guardar por duplicado, los elementos que son comunes a varias versiones. El repositorio
nos va a facilitar el almacenaje de la informacin de la evolucin del sistema, ya que, aparte de los datos en
s mismo, tambin almacena informacin sobre las versiones, temporizacin, etc.
El entorno de desarrollo integrado Netbeans usa como sistema de control de versiones CVS. Este sistema,
tiene un componente principal, que es el repositorio. En el repositorio se debern almacenar todos los
ficheros de los proyectos, que puedan ser accedidos de forma simultnea por varios desarrolladores.
Cuando usamos una sistema de control de versiones, trabajamos de forma local, sincronizndonos con el
repositorio, haciendo los cambios en nuestra copia local, realizado el cambio, se acomete el cambio en el
repositorio. Para realizar la sincronizacin, en el entorno Netbeans, lo realizamos de varias formas:
Abriendo un proyecto CVS en el IDE.
Comprobando los archivos de un repositorio.
Importando los archivos hacia un repositorio.
Si tenemos un proyecto CVS versionado, con el que hemos trabajado, podemos abrirlo en el IDE y
podremos acceder a las caractersticas de versionado. El IDE escanea nuestro proyectos abiertos y si
contienen directorios CVS, el estado del archivo y la ayuda-contextual se activan automticamente para los
proyectos de versiones CVS. En el siguiente enlace podemos ver acceder a un archivo que amplia la
informacin sobre el repositorio CVS.
Repositorio CVS

Autoevaluacin
Qu afirmacin sobre control de versiones es correcta?
Solo puede existir una nica versin de una clase.
El almacenamiento de versiones es local a cada mquina.

29/06/2013 13:49

ED04_Contenidos

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

El repositorio centraliza el almacenamiento de los datos.

Muy bien. El repositorio es la parte fundamental en el control de versiones, ya que almacena
todos los datos de los proyectos.

15 de 36

29/06/2013 13:49

ED04_Contenidos

16 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

2.3.- Herramientas de control de versiones.

Caso prctico
Mara quiere que Carlos conozca las herramientas de
control de versiones que integra Netbeans, ya que es el
Entorno que utilizan para su desarrollo. Dado que estamos
utilizando un Entorno de Desarrollo Integrado, Carlos debe
conocer las herramientas que incorpora Netbeans.

Durante el proceso de desarrollo de software, donde todo un

equipo de programadores estn colaborando en el desarrollo de
un proyecto software, los cambios son continuos. Es por ello
necesario que existan en todos los lenguajes de programacin y
en todos los entornos de programacin, herramientas que
gestionen el control de cambios.
Si nos centramos en Java, actualmente destacan dos
herramientas de control de cambios: CVS y Subversion. CVS es una herramienta de cdigo abierto
ampliamente utilizada en numerosas organizaciones. Subversion es el sucesor natural de CVS, est
rpidamente integrndose en los nuevos proyectos Java, gracias a sus caractersticas que lo hacen
adaptarse mejor a las modernas prcticas de programacin Java. Estas dos herramienta de control de
versiones, se integran perfectamente en los entornos de desarrollado para Java, como Netbeans y Eclipse.
Otras herramientas de amplia difusin son:
SourceSafe: es una herramienta que forma parte del entorno de desarrollo Microsoft Visual Studio.
Visual Studio Team Foundation Server: es el sustituto de Source Safe. Es un productor que ofrece
control de cdigo fuente, recoleccin de datos, informes y seguimiento de proyectos, y est
destinado a proyectos de colaboracin de desarrollo de software.
Darcs: es un sistema de gestin de versiones distribuido. Algunas de sus caractersticas son: la
posibilidad de hacer
commits locales (sin conexin), cada repositorio es una rama en s misma,
independencia de un servidor central, posibilidad de renombrar ficheros, varios mtodos de acceso
como local,
ssh, http y
ftp, etc.
Git: esta herramienta de control de versiones, diseada por Linus Torvalds.
Mercurial: esta herramienta funciona en Linux, Windows y Mac OS X, Es un programa de lnea de
comandos. Es una herramienta que permite que el desarrollo se haga distribuido, gestionando de
forma robusta archivos de texto y binarios. Tiene capacidades avanzadas de ramificacin e
integracin. Es una herramienta que incluye una interfaz web para su configuracin y uso.

29/06/2013 13:49

ED04_Contenidos

17 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

Autoevaluacin
Qu herramienta no es una herramienta de Control de Versiones?
Subversion.
CVS.
Mercurial.
PMD.
Correcta. PMD es un analizador de cdigo.

29/06/2013 13:49

ED04_Contenidos

18 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

2.4.- Planificacin de la gestin de configuraciones.

Caso prctico
El equipo de desarrollo de BK Programacin decide reunirse
para planificar la gestin de configuraciones, ya que la
aplicacin de Gestin Hotelera es amplia y compleja, y
continuamente se estn diseando nuevos mdulos, clases o
mtodos.

La Gestin de Configuraciones del software (GCS) es un conjunto de actividades

desarrolladas para gestionar los cambios a lo largo del ciclo de vida.
La planificacin de las Gestin de Configuraciones del software, est regulado en el
estndar IEEE 828.

Cuando se habla de la gestin de configuraciones, se est haciendo referencia a la evolucin de todo un

conjunto de elementos. Una configuracin es una combinacin de versiones particulares de los
componentes que forman un sistema consistente. Desde el punto de vista de la evolucin en el tiempo, es
el conjunto de las versiones de los objetos componentes en un instante dado.
Una configuracin puede cambiar porque se aaden, eliminan o se modifican elementos. Tambin puede
cambiar, debido a la reorganizacin de los componentes, sin que estos cambien.
Como consecuencia de lo expuesto, es necesario disponer de un mtodo, que nos permita designar las
diferentes configuraciones de manera sistemtica y planificada. De esta forma se facilita el desarrollo de
software de manera evolutiva, mediante cambios sucesivos aplicados a partir de una configuracin inicial
hasta llegar a una versin final aceptable del producto.
La Gestin de Configuraciones de Software se va a componer de cuatro tareas bsicas:
1. Identificacin. Se trata de establecer estndares de documentacin y un esquema de identificacin
de documentos.
2. Control de cambios. Consiste en la evaluacin y registro de todos los cambios que se hagan de la
configuracin software.
3. Auditoras de configuraciones. Sirven, junto con las revisiones tcnicas formales para garantizar
que el cambio se ha implementado correctamente.
4. Generacin de informes. El sistema software est compuesto por un conjunto de elementos, que
evolucionan de manera individual, por consiguiente, se debe garantizar la consistencia del conjunto
del sistema.
La planificacin de la Gestin de Configuraciones de Software va a comprender diferentes actividades:
1. Introduccin (propsito, alcance, terminologa).
2. Gestin de GCS (organizacin, responsabilidades, autoridades, polticas aplicables, directivas y
procedimientos).
3. Actividades GCS (identificacin de la configuracin, control de configuracin, etc.).
4. Agenda GCS (coordinacin con otras actividades del proyecto).
5. Recursos GCS (herramientas, recursos fsicos y humanos).
6. Mantenimiento de GCS.

29/06/2013 13:49

ED04_Contenidos

19 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

2.5.- Gestin del cambio.

Caso prctico
Para gestionar el control de versiones de forma centralizada, Ada va a
supervisar los cambios de versin que el equipo de Juan y de Mara
estn efectuando de forma independiente. Ada va a realizar una gestin
del cambio centralizada y organizada.

Las herramientas de control de versiones no garantizan un

desarrollo razonable, si cualquier componente del equipo de
desarrollo de una aplicacin puede realizar cambios e integrarlos
en el repositorio sin ningn tipo de control. Para garantizar que
siempre disponemos de una lnea base para continuar el
desarrollo, es necesario aplicar controles al desarrollo e
integracin de los cambios. El control de cambios es un
mecanismo que sirve para la evaluacin y aprobacin de los
cambios hechos a los elementos de configuracin del software.
Pueden establecerse distintos tipos de control:
1. Control individual, antes de aprobarse un nuevo elemento.
Cuando un elemento de la configuracin est bajo control individual, el programador responsable
cambia la documentacin cuando se requiere. El cambio se puede registrar de manera informal, pero
no genera ningn documento formal.
2. Control de gestin u organizado, conduce a la aprobacin de un nuevo elemento.
Implica un procedimiento de revisin y aprobacin para cada cambio propuesto en la configuracin.
Como en el control individual, el control a nivel de proyecto ocurre durante el proceso de desarrollo
pero es usado despus de que haya sido aprobado un elemento de la configuracin software. El
cambio es registrado formalmente y es visible para la gestin.
3. Control formal, se realiza durante el mantenimiento.
Ocurre durante la fase de mantenimiento del ciclo de vida software. El impacto de cada tarea de
mantenimiento se evala por un Comit de Control de Cambios, el cul aprueba la modificaciones de
la configuracin software.

Autoevaluacin
Cul de las siguientes no es una tarea bsica de la Gestin de Configuraciones del
Software?
Control de cambios.
Generacin de informes.
Auditoras de configuraciones.

29/06/2013 13:49

ED04_Contenidos

20 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

Gestin del repositorio.

Muy bien. El repositorio es un elemento del control de versiones.

29/06/2013 13:49

ED04_Contenidos

21 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

2.6.- Gestin de versiones y entregas.

Caso prctico
Mara ha desarrollado varias versiones del mdulo de
reservas de la aplicacin de Gestin Hotelera. Le explica a
Carlos como ha sido la evolucin de cada versin del
mdulo, desde la primera versin, hasta la versin actual,
que ella cree definitiva.

Las versiones hacen referencia a la evolucin de un nico

elemento, dentro de un sistema software. La evolucin puede
representarse en forma de grafo, donde los nodos son las
versiones y los arcos corresponden a la creacin de una versin a
partir de otra ya existente.
Grafo de evolucin simple: las revisiones sucesivas de un componente dan lugar a una simple secuencia
lineal. Esta evolucin no presenta problemas en la organizacin del repositorio y las versiones se designan
mediante nmeros correlativos.
Variantes: en este caso, existen varias versiones del componente. El grafo ya no es una secuencia lineal, si
no que adopta la forma de un rbol. La numeracin de las versiones requerir dos niveles. El primer nmero
designa la variante (lnea de evolucin) y el segundo la versin particular (revisin) a lo largo de dicha
variante.
La terminologa que se usa para referirse a los elementos del grafo son:
Tronco (trunk): es la variante principal.
Cabeza (head): es la ltima versin del tronco.
Ramas (branches): son la variantes secundarias.
Delta: es el cambio de una revisin respecto a la anterior.
Propagacin de cambios: cuando se tienen variantes que se desarrollan en paralelo, suele ser necesario
aplicar un mismo cambio a varias variantes.
Fusin de variantes: en determinados momentos puede dejar de ser necesario mantener una rama
independiente. En este caso se puede fundir con otra (MERGE).
Tcnicas de almacenamiento: como en la mayora de los casos, las distintas versiones tienen en comn
gran parte de su contenido, se organiza el almacenamiento para que no se desaproveche espacio
repitiendo los datos en comn de varias versiones.
Deltas directos: se almacena la primera versin completa, y luego los cambios mnimos necesarios
para reconstruir cada nueva versin a partir de la anterior.
Deltas inversos: se almacena completa la ltima versin del tronco y los cambios necesarios para
reconstruir cada versin anterior a partir de la siguiente. En las ramas se mantiene el uso de los
deltas directos.
Marcado selectivo: se almacena el texto refundido de todas las versiones como una secuencia
lineal, marcando cada seccin del conjunto con los nmeros de versiones que corresponde.
En cuanto a la gestin de entregas, en primer lugar definimos el concepto de entrega como una instancia
de un sistema que se distribuye a los usuarios externos al equipo de desarrollo.
La planificacin de la entrega se ocupa de cundo emitir una versin del sistema como una entrega. La
entrega est compuesta por el conjunto de programas ejecutables, los archivos de configuracin que
definan como se configura la entrega para una instalacin particular, los archivos de datos que se necesitan

29/06/2013 13:49

ED04_Contenidos

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

para el funcionamiento del sistema, un programa de instalacin para instalar el sistema en el hardware de
destino, documentacin electrnica y en papel, y, el embalaje y publicidad asociados, diseados para esta
entrega Actualmente los sistemas se entregan en discos pticos (CD o DVD) o como archivos de instalacin
descargables desde la red.

22 de 36

29/06/2013 13:49

ED04_Contenidos

23 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

2.7.- Herramientas CASE para la gestin de configuraciones.

Caso prctico
Ada decide utilizar herramientas CASE, de cdigo abierto, para la
gestin de configuraciones. Decide utilizar Bugzilla, ya que puede
integrarse con Netbeans.

Los procesos de gestin de configuraciones estn estandarizados

y requieren la aplicacin de procedimientos predefinidos, ya que
hay que gestionar gran cantidad de datos. Cuando se construye un
sistema a partir de versiones de componentes, un error de gestin
de configuraciones, puede implicar que el software no trabaje
correctamente. Por todo ello, las herramientas CASE de apoyo son
imprescindibles para la gestin de configuraciones.
Las herramientas se pueden combinar con entornos de trabajo de gestin de configuraciones. Hay dos tipos
de entornos de trabajo de Gestin de Configuraciones:
Entornos de trabajo abiertos: las herramientas de Gestin de Configuraciones son integradas de
acuerdo con procedimientos organizacionales estndar. Nos encontramos con bastantes
herramientas de Gestin de Configuraciones comerciales y
open-source disponibles para
propsitos especficos. La gestin de cambios se puede llevar a cabo con herramientas de
seguimiento (bug-tracking) como Bugzilla, la gestin de versiones a travs de herramientas como
RCS o CVS, y la construccin del sistema con herramientas como Make o Imake. Estas
herramientas son open-source y estn disponibles de forma gratuita.
Entornos integrados: estos entorno ofrecen facilidades integradas para gestin de versiones,
construccin del sistema o seguimiento de los cambios. Por ejemplo, est el proceso de control de
Cambios Unificado de Rational, que se basa en un entorno de Gestin de Configuraciones que
incorpora ClearCase para la construccin y gestin de versiones del sistema y ClearQuest para el
seguimiento de los cambios. Los entornos de Gestin de Configuraciones integrado, ofrecen la
ventaja de un intercambio de datos sencillos, y el entorno ofrece una base de datos de Gestin de
Configuraciones integrada.

29/06/2013 13:49

ED04_Contenidos

24 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

Autoevaluacin
La Gestin de Configuraciones:
Verifica la evolucin de la implementacin de una clase.
Es una tarea que se puede gestionar con herramientas de Control de Versiones.
Es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo
de vida del software.
Muy bien.

29/06/2013 13:49

ED04_Contenidos

25 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

2.8.- Clientes de control de versiones integrados en el entorno

de desarrollo.

Caso prctico
Juan le va a ensear a Ana los clientes de control de
versiones que hay en Netbeans, para que aprenda a utilizarlos
e integrarlos en los proyectos que realice de ahora en
adelante.

Los entornos de desarrollo actuales integran de forma generalizada, clientes de control de versiones. En
algunos caso, como puede ser el IDE Microsoft Visual Studio, se utiliza Visual Studio Team Foundation, de
tal forma, que se realiza una gestin centralizada de un proyecto desarrollado por un equipo, incluyendo la
gestin de configuraciones de software, la gestin de versiones, y dems aspectos de un desarrollo en
equipo.
Los entorno de desarrollo Open-Source, como Eclipse y Netbeans, los integran de manera directa, o bien
instalndolos como plug-in (complementos). Los clientes de control de versiones ms destacados son:
CVS.
Subversion.
Mercurial.

Debes conocer
Debes leer el siguiente documento para conocer las herramientas de control de versiones de
Netbeans.
Clientes de Control de Versiones en Netbeans
Tambin debes visitar el siguiente enlace donde se puede ver la gua de uso de subversin en
Netbeans. Est en ingls pero es conveniente que le eches un vistazo para conocer cmo
funciona Subversion.
Gua de uso de Subversion en Netbeans.

Autoevaluacin
Qu cliente de Gestin de Versiones no incorpora Netbeans?
VS Team Foundation.
CVS.
Mercurial.
Muy bien. Visual Studio Team Foundation, est diseada para el trabajo colaborativo y

29/06/2013 13:49

ED04_Contenidos

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

control de versiones en Microsoft Visual Studio.

26 de 36

29/06/2013 13:49

ED04_Contenidos

27 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

3.- Documentacin.

Caso prctico
Juan y Mara saben de la importancia de tener documentado
el cdigo y todo el proceso de desarrollo de software. Al
mismo tiempo que codifican y refactorizan, dejan constancia
documental de lo que van haciendo. Como estn
desarrollando con Netbeans, y con el objetivo de facilitar su
trabajo de documentacin, van a utilizar JavaDoc. Ana y
Antonio consiguen entender el funcionamiento de la
aplicacin, y la funcin de cada mtodo, gracias a los
comentarios que insertan en el cdigo los dos programadores
principales.

El proceso de documentacin de cdigo, es uno de los aspectos

ms importantes de la labor de un programador. Documentar el
cdigo nos sirve para explicar su funcionamiento, punto por punto,
de forma que cualquier persona que lea el comentario, puede
entender la finalidad del cdigo.
La labor de documentacin es fundamental para la deteccin de
errores y para su mantenimiento posterior, que en muchos casos,
es realizado por personas diferentes a las que intervinieron en su
creacin. Hay que tener en cuenta que todos los programas tienen
errores y todos los programas sufren modificaciones a los largo de su vida.
La documentacin aade explicaciones de la funcin del cdigo, de las caractersticas de un mtodo, etc.
Debe tratar de explicar todo lo que no resulta evidente. Su objetivo no es repetir lo que hace el cdigo, sino
explicar por qu se hace.
La documentacin explicar cul es la finalidad de un clase, de un paquete, qu hace un mtodo, para qu
sirve una variable, qu se espera del uso de una variable, qu algoritmo se usa, por qu hemos
implementado de una manera y no de otra, qu se podra mejorar en el futuro, etc.

Para saber ms
El siguiente enlace nos muestra el estilo de programacin a seguir en Java, as como la forma de
documentar y realizar comentarios de un cdigo. (En ingls)
Documentacin y comentarios en Java

29/06/2013 13:49

ED04_Contenidos

28 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

3.1.- Uso de comentarios.

Caso prctico
Carlos est aprendiendo muchas cosas con Mara. Sin
embargo hay algunos mtodos y clases que ha implementado
Mara, y que no logra entender. Mara le comenta que va a
incluir comentarios en su cdigo, y le va a ensear la forma
correcta de hacerlo.

Uno de los elementos bsicos para documentar cdigo, es el uso

de comentarios. Un comentario es una anotacin que se realiza en
el cdigo, pero que el
compilador va a ignorar, sirve para indicar
a los desarrolladores de cdigo diferentes aspectos del cdigo que
pueden ser tiles. En principio, los comentarios tienen dos
propsitos diferentes:
Explicar el objetivo de las sentencias. De forma que el
programador o programadora, sepa en todo momento la funcin de esa sentencia, tanto si lo
disearon como si son otros los que quieren entenderlo o modificarlo.
Explicar qu realiza un mtodo, o clase, no cmo lo realiza. En este caso, se trata de explicar los
valores que va a devolver un mtodo, pero no se trata de explicar cmo se ha diseado.
En el caso del lenguaje Java, C# y C, los comentarios, se implementan de forma similar. Cuando se trata de
explicar la funcin de una sentencia, se usan los caracteres // seguidos del comentario, o con los caracteres
/* y */, situando el comentario entre ellos: /* comentario */
Otro tipo de comentarios que se utilizan en Java, son los que se utilizan para explicar qu hace un cdigo,
se denominan comentarios JavaDoc y se escriben empezando por /** y terminando con */ , estos
comentarios pueden ocupar varias lneas. Este tipo de comentarios tienen que seguir una estructura
prefijada.
Los comentarios son obligatorios con JavaDoc, y se deben incorporar al principio de cada clase, al principio
de cada mtodo y al principio de cada variable de clase. No es obligatorio, pero en muchas situaciones es
conveniente, poner los comentarios al principio de un fragmento de cdigo que no resulta lo suficientemente
claro, a la largo de bucles, o si hay alguna lnea de cdigo que no resulta evidente y pueda llevarnos a
confusin.
Hay que tener en cuenta, que si el cdigo es modificado, tambin se debern modificar los comentarios.

29/06/2013 13:49

ED04_Contenidos

29 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

3.2.- Alternativas.

Caso prctico
Juan le explica a Mara, que para documentar el software,
existen diferentes formas de hacerlo y distintas herramientas
en el mercado que automatizan la tarea de documentacin.

En la actualidad, el desarrollo rpido de aplicaciones, en muchos casos, va en detrimento de una buena

documentacin del cdigo. Si el cdigo no est documentado, puede resultar bastante difcil de entender, y
por tanto de solucionar errores y de mantenerlo.
La primera alternativa que surge para documentar cdigo, son los comentarios. Con los comentarios,
documentamos la funcionalidad de una lnea de cdigo, de un mtodo o el comportamiento de una
determinada clase.
Existen diferentes herramientas que permiten automatizar, completar y enriquecer nuestra documentacin.
Podemos citar JavaDoc, SchemeSpy y Doxygen, que producen una documentacin actualizada, precisa y
utilizable en lnea, incluyendo adems, con SchemeSpy y Doxygen, modelos de bases de datos grficos y
diagramas.
Insertando comentario en el cdigo ms difcil de entender, y utilizando la documentacin generada por
alguna de las herramientas citadas anteriormente, se genera la suficiente informacin para ayudar a
cualquier nuevo programador o programadora.

Autoevaluacin
Un comentario en formato JavaDoc.
Utiliza los caracteres //
Comienzan con /* y termina por */
Comienza por /** y terminan por */
Muy bien. Es la manera de comenzar y termina un comentario con JavaDoc.

29/06/2013 13:49

ED04_Contenidos

30 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

3.3.- Documentacin de clases.

Caso prctico
Juan va a utilizar JavaDoc para documentar las clases que ha
desarrollado. Ana se da cuenta de la ayuda tan importante
que ofrece, tanto para el futuro mantenimiento de la aplicacin
como para entender su funcionamiento, tener documentadas
las clases.

Las clases que se implementan en un aplicacin, deben de incluir

comentarios. Al utilizar un entorno de programacin para la
implementacin de la clase, debemos seguir una serie de pautas,
muchas de las cuales las realiza el IDE de forma trasparente, en el
diseo y documentacin del cdigo. Cuando se implementa una clase,
se deben incluir comentarios. En el lenguaje Java, los criterios de
documentacin de clases, son los establecidos por JavaDoc.
Los comentarios de una clase deben comenzar con /** y terminar con */
. Entre la informacin que debe incluir un comentario de clase debe
incluirse, al menos las etiquetas @author y @version, donde @author
identifica el nombre del autor o autora de la clase y @version, la
identificacin de la versin y fecha.
Con el uso de los entornos de desarrollo, las etiquetas se aaden de forma automtica, estableciendo el
@author y la @version de la clase de forma transparente al programador-programadora. Tambin se suele
aadir la etiqueta @see, que se utiliza para referenciar a otras clases y mtodos.
Dentro de la la clase, tambin se documentan los constructores y los mtodos. Al menos se indican las
etiquetas:
@param: seguido del nombre, se usa para indicar cada uno de los parmetros que tienen el
constructor o mtodo.
@return: si el mtodo no es void, se indica lo que devuelve.
@exception: se indica el nombre de la excepcin, especificando cuales pueden lanzarse.
@throws: se indica el nombre de la excepcin, especificando las excepciones que pueden lanzarse.
Los campos de una clase, tambin pueden incluir comentarios, aunque no existen etiquetas obligatorias en
JavaDoc.

29/06/2013 13:49

ED04_Contenidos

31 de 36

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

3.4.- Herramientas.

Caso prctico
Para documentar el cdigo, el equipo de desarrollo de BK
Programacin, ha decidido utilizar JavaDoc, por lo que todos
los componentes del equipo de desarrollo, debe
familiarizarse con la herramienta.

Los entornos de programacin que implementa Java, como Eclipse

o Netbeans, incluyen una herramienta que va a generar pginas
HTML de documentacin a partir de los comentarios incluidos en
el cdigo fuente. La herramienta ya se ha indicado en los puntos
anteriores, y es JavaDoc. Para que JavaDoc pueda generar las
pginas HTML es necesario seguir una serie de normas de
documentacin en el cdigo fuente, estas son:
Los comentarios JavaDoc deben empezar por /** y terminar
por */.
Los comentarios pueden ser a nivel de clase, a nivel de variable y a nivel de mtodo.
La documentacin se genera para mtodos public y protected.
tag para documentar diferentes aspectos determinados del cdigo, como
Se puede usar
parmetros.
Los tags ms habituales son los siguientes:

Tags ms habituales.
Tipo de tag

Formato

Descripcin

Todos.

@see.

Permite crear una referencia a la documentacin de otra clase o mtodo.

Clases.

@version.

Comentario con datos indicativos del nmero de versin.

Clases.

@author.

Nombre del autor.

Clases.

@since.

Fecha desde la que est presente la clase.

Mtodos.

@param.

Parmetros que recibe el mtodo.

Mtodos.

@return.

Significado del dato devuelto por el mtodo

Mtodos.

@throws.

Comentario sobre las excepciones que lanza.

Mtodos.

@deprecated.

Indicacin de que el mtodo es obsoleto.

29/06/2013 13:49

ED04_Contenidos

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

Anexo I.- Repositorio CVS.

Conectar con un repositorio.
Si queremos conectar con un repositorio remoto desde el IDE, entonces chequearemos los ficheros e
inmediatamente comenzar a trabajar con ellos. Se hace de la siguiente forma:
1. En el IDE NetBeans elegimos Herramientas - CVS - Extraer. El asistente para extraer el modulo se
nos abrir.
2. En el primer panel del asistente, se introduce la localizacin del repositorio definido con
CVSROOT. El IDE soporta diferentes formatos de CVSROOT, dependiendo de si el repositorio es local o
remoto, y del mtodo utilizado para conectarnos a l.

Mtodos de conexin a CVSROOT

Mtodo
pserver

ext

local

fork

Descripcin
Contrasea
remoto.

de

Ejemplo
servidor

:pserser:username@hotsname:/repository_path

Acceso usando Remote Shell

(RSH) o Secure Shell (SSH).

:ext:username@hostname:/repository_path

Acceso a un repositorio local.

:local:/repository_path
(requiere un CVS externo ejecutable)

Acceso a un repositorio local

usando un protocolo remoto.

:fork:/repository_path
(requiere un CVS externo ejecutable)

3. En el panel de Mdulos a extraer del asistente, especificamos el mdulo que queremos extraer, en el
campo Mdulo. Si no sabemos el nombre del mdulo, podemos extraerlo haciendo clic en el botn
Examinar. Si lo que queremos es conectar a un repositorio remoto desde el IDE, debemos extraer los
ficheros e inmediatamente trabajar con ellos, se hace de la siguiente forma:

4. En el campo de texto, ponemos el nombre del Mdulo que queremos extraer. Podemos usar el botn
Examinar, para buscar aquellos mdulos disponibles.
5. En el campo Carpeta local, pondremos la ruta de nuestro ordenador donde queremos extraer los
archivos. Pulsaremos el botn Terminar para que el proceso comience.
Importar archivos hacia un repositorio.
Alternativamente, podemos importar un proyecto en el que estemos trabajando en el IDE hacia un
repositorio remoto, seguiremos trabajando en el IDE despus de que haya sido versionado con el
repositorio CVS.
Para importar un proyecto a un repositorio:
1. Desde la ventana de proyectos, seleccionamos un proyecto que no este versionado, y elegimos
Equipo - CVS - Importar al depsito. Se abrir el asistente de importacin CVS.
2. En el panel Raz CVS del asistente, se especifica la localizacin del repositorio definido como
CVSROOT . Dependiendo del mtodo usado, necesitaremos utilizar ms informacin, como la
contrasea o configuracin del proxy, para conectarnos a un repositorio remoto.
3. En Carpeta a importar, se especifica el directorio local donde queremos colocar el repositorio.

32 de 36

29/06/2013 13:49

ED04_Contenidos

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

4. En el rea de texto Importar mensaje, pondremos una descripcin del proyecto que estamos
importando.
5. Se especifica la localizacin del repositorio donde queremos importar el proyecto, escribiendo la ruta
en Carpeta del depsito. De forma alternativa, se puede hacer clic en el botn Examinar para ir a
una localizacin especifica en el repositorio. Al hacer clic en el botn Terminar se inicia la
importacin. El IDE copiara los ficheros del proyecto en el repositorio.

33 de 36

29/06/2013 13:49

ED04_Contenidos

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

Anexo II.- Clientes de Control de Versiones en Netbeans.

El entorno de desarrollo integrado NetBeans 6.9.1., incorpora tres clientes de control de versiones. Estos
tres clientes son CVS, Subversion y Mercurial.
Cuando estemos desarrollando una aplicacin, si queremos gestionar el control de versiones, podemos
utilizar cualquiera de los tres.

CVS
En el caso del IDE NetBeans, es importante su uso para mantener de forma segura, tanto los programas
como las pruebas, en un repositorio de cdigo. La configuracin de CVS puede suponer unos cinco
minutos, que dentro del tiempo de desarrollo de una aplicacin, es un tiempo despreciable. Sin embargo, el
uso de CVS en NetBeans, nos va a gestionar las distintas versiones del cdigo que se desarrollen y nos va
a evitar prdidas de datos y de cdigo.
Para utilizar CVS, es necesario la instalacin de un cliente CVS, sin embargo, NetBeans nos va a evitar
esta instalacin, ya que incorpora un cliente CVS en Java.
CVS se puede utilizar con NetBeans de tres formas:
1. Desde la lnea de comando CVS, donde se escribirn los comandos CVS y de esta forma se
interactuar con el repositorio.
2. Si CVS est incorporado a NetBeans, dispondremos de un conjunto de clases Java que imitan los
comandos clsicos de CVS.
3. Con frmulas de lnea de comandos CVS genricas basadas en plantillas proporcionadas por el
usuario, que son pasadas al shell del sistema operativo.
En los casos anteriores, donde se utilizan plantillas, las plantillas estn parametrizadas, con la lgica
NetBeans, que sustituye los operadores CVS por variables. Esto quiere decir, que NetBeans se va a
encargar de decidir el nombre de los ficheros, que datos se importan o exportan del repositorio, sin que el
usuario deba conocer toda la lgica interna de CVS. Nos evitamos tener que conocer todos los parmetros
y opciones necesarias para realizar las operaciones con CVS.
SUBVERSION
Subversion es un sistema de control de versiones de software libre, que se ha convertido en el sustituto
natural de CVS. A diferencia de CVS, los archivos que se versionan no tienen un nmero de versin
independiente, todo el repositorio tiene un nico nmero de versin que identifica un estado comn de
todos los archivos del repositorio en un instante determinado.
Subversion puede acceder al repositorio a travs de redes. Esto implica que varias personas pueden
acceder, modificar y administrar el mismo conjunto de datos, con lo que se va a fomentar la colaboracin.
Se puede progresar ms rpidamente sin un nico conducto por el cual deban pasar todas las
modificaciones. Y puesto que el trabajo se encuentra bajo el control de versiones, no se compromete la
calidad del software que se desarrolla.
Recuerda visitar la gua de Subversion que te sugerimos en la unidad de trabajo.
MERCURIAL
Mercurial es un sistema de control de versiones que utiliza sobre todo la lnea de comandos. Todas las
operaciones de Mercurial se invocan como opciones dadas a su motor hg. Las principales metas de
Mercurial incluyen un gran rendimiento y escalabilidad, desarrollo completamente distribuido, sin necesidad

34 de 36

29/06/2013 13:49

ED04_Contenidos

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

de un servidor, gestin robusta de archivos de texto y binarios, y capacidades avanzadas de ramificacin e

integracin.

35 de 36

29/06/2013 13:49

ED04_Contenidos

http://catedu.es/fpmoodle/file.php/105/ED04/ED04_Web/index.html

Anexo.- Licencias de recursos.

Licencias de recursos utilizados en la Unidad de Trabajo.
Recurso (1)

Datos del recurso (1)

Recurso (2)

Datos del recurso (2)

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

Autora: Gnome.org.
Licencia: GNU.
Procedencia: Captura de
pantalla de gnome.org.

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

Autora:
Oracle
Corporation.
Licencia: Copyright cita.
Procedencia: Captura de
pantalla de Netbeans.

36 de 36

29/06/2013 13:49