Optimización y documentación.

Caso práctico

Mujer de pelo corto y chaqueta negra mirando de frente.

Situación

BK programación se encuentra desarrollando la aplicación de gestión hotelera.

Como parte del proceso de desarrollo surgen una serie de problemas: hay un código que presenta algunas implementaciones que se pueden mejorar aplicando refactorización, nos encontramos que los miembros del equipo de desarrollo están modificando constantemente métodos o clases, creando diferentes versiones de las mismas y falta una documentación clara y precisa del código.

Ada propone a Juan y a María (programadores principales de la aplicación) que usen los patrones generales de refactorización para conseguir un código de mejor calidad, más fácil de entender, más fácil de probar y con menor probabilidad de generar errores. Ana va a intentar ayudar a Juan, y Carlos a María, pero no conocen nada de refactorización, ni entiende la necesidad de realizar este trabajo "extra".

Como todos los miembros de BK Programación 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 configuración del software.

Los miembros con menor experiencia, Carlos y Ana, van a ir generando, utilizando herramientas de documentación automatizadas, la documentación de las clases y del código generado por Juan y María.

Ada va a encargarse de la Gestión de Configuraciones del Software, ya que es una labor fundamental para cualquier jefe de proyecto. Asimismo, debe garantizar que el código generado por Juan y María esté refactorizado.

Ilustración del logotipo del Ministerio de Educación y Formación Profesional. — Ministerio de Educación y Formación Profesional. (Dominio público)

Materiales formativos de FP Online propiedad del Ministerio de Educación y Formación Profesional.
Aviso Legal

1.- Refactorización.

Caso práctico

Imagen de cinco personas sentadas en una mesa, donde hay un proyector funcionando y una mujer explicando algo, mirando hacia una pantalla.

Gran parte de las clases, métodos y módulos que forman parte de la aplicación de Gestión Hotelera han sido implementados, surge ahora una pregunta. ¿Podemos mejorar la estructura del código y que sea de mayor calidad, sin que cambie su comportamiento? ¿Cómo hacerlo? ¿Qué patrones hay que seguir?

¿Podemos mejorar la estructura del código y que sea de mayor calidad, sin que cambie su comportamiento? ¿Cómo hacerlo? ¿Qué patrones hay que seguir?.

La refactorización es una técnica, que consiste en realizar pequeñas transformaciones en el código de un programa, para mejorar la estructura sin que cambie el comportamiento ni funcionalidad del mismo. Su objetivo es mejorar la estructura, la legibilidad o la eficiencia del código.

Con la refactorización se mejora el diseño del software, hace que el software sea más fácil de entender, hace que el mantenimiento del software sea más sencillo, la refactorización ayuda a que el programa sea más rápido.

La idea de refactorización de código, se basa en el concepto matemático de factorización de polinomios. Así, resulta que (x + 1)(x − 1) se puede expresar como x² − 1 sin que se altere su sentido.

Algunas pistas que nos pueden indicar la necesidad de refactorizar un programa son:

Código duplicado.
Métodos demasiado largos.
Clases muy grandes o con demasiados métodos.
Métodos más interesados en los datos de otra clase que en los de la propia.
Grupos de datos que suelen aparecer juntos y parecen más una clase que datos sueltos.
Clases con pocas llamadas o que se usan muy poco.
Exceso de comentarios explicando el código.

Hay que resaltar que la refactorización no cambia el comportamiento observable del software. El software sigue cumpliendo la misma función que hacía antes. Ningún usuario, ya sea usuario final u otro programador, podrá determinar qué cosas han cambiado.

Para saber más

Puedes visitar la siguiente página web (en inglés), donde se presenta el proceso de refactorización de aplicaciones Java con Netbeans.

Refactorización en Netbeans.

1.1.- Concepto.

Caso práctico

Juan va a empezar a refactorizar parte del código que ha generado. Ana no sabe que es refactorizar, así que Juan le va a explicar las bases del proceso de refactorización.

El concepto de refactorización de código, se base en el concepto matemático de factorización de polinomios.

Podemos definir el concepto de refactorización de dos formas:

Refactorización: Cambio hecho en la estructura interna del software para hacerlo más fácil de entender y fácil de modificar sin modificar su comportamiento.
Ejemplos de refactorización es "Extraer Método" y "Encapsular Campos". La refactorización es normalmente un cambio pequeño en el software que mejora su mantenimiento.
Campos encapsulados: Se aconseja crear métodos getter y setter, (de asignación 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 método getter o setter según convenga.
Refactorizar: Reestructurar el software aplicando una serie de refactorizaciones sin cambiar su comportamiento.

El propósito de la refactorización es hacer el software más fácil de entender y de modificar. Se pueden hacer muchos cambios en el software que pueden hacer algún pequeño cambio en el comportamiento observable. Solo los cambios hechos para hacer el software más fácil de entender son refactorizaciones.

Hay que diferenciar la refactorizacón de la optimización. En ambos procesos, se pretende mejorar la estructura interna de una aplicación o componente, sin modificar su comportamiento. Sin embargo, cuando se optimiza, se persigue una mejora del rendimiento, por ejemplo mejorar la velocidad de ejecución, pero esto puede hacer un código más difícil de entender.

Hay que resaltar que la refactorización no cambia el comportamiento observable del software. El software sigue cumpliendo la misma función que hacia antes. Ningún usuario, ya sea usuario final u otro programador, podrá determinar que cosas han cambiado.

Reflexiona

Con la refactorización de código, estamos modificando un código que funciona correctamente, ¿merece la pena el esfuerzo de refactorizar un código ya implementado?

1.2.- Limitaciones.

Caso práctico

Mujer joven, de pie, con camisa azul y mirando de frente.

Ana se muestra muy interesada por conocer esta técnicas avanzadas se programación, sin embargo Juan le pone los pies en el suelo, explicándole que son técnicas con muchas limitaciones y poca documentación en la que basarse.

La refactorización es un técnica lo suficientemente novedosa para conocer cuáles son los beneficios que aporta, pero falta experiencia para conocer el alcance total de sus limitaciones. Se ha constatado que la refactorización presente problemas en algunos aspectos del desarrollo.

Un área problemática de la refactorización 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 modificación que se requiera de las bases de datos, incluyendo modificación de esquema y migración de datos, puede ser una tarea muy costosa. Es por ello que la refactorización de una aplicación asociada a una base de datos, siempre será limitada, ya que la aplicación dependerá del diseño de la base de datos.

Otra limitación, es cuando cambiamos interfaces. Cuando refactorizamos, estamos modificando la estructura interna de un programa o de un método. El cambio interno no afecta al comportamiento ni a la interfaz. Sin embargo, si renombramos un método, hay que cambiar todas las referencias que se hacen a él. Siempre que se hace esto se genera un problema si es una interfaz pública. Una solución 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 diseño que son difíciles de refactorizar. Es muy difícil refactorizar cuando hay un error de diseño o no es recomendable refactorizar, cuando la estructura a modificar es de vital importancia en el diseño de la aplicación.

Hay ocasiones en las que no debería refactorizar en absoluto. Nos podemos encontrar con un código que, aunque se puede refactorizar, sería más fácil reescribirlo desde el principio. Si un código no funciona, no se refactoriza, se reescribe.

Autoevaluación

Solución

Incorrecto (Retroalimentación)
Incorrecto (Retroalimentación)
Opción correcta (Retroalimentación)
Incorrecto (Retroalimentación)

1.3.- Patrones de refactorización más habituales.

Caso práctico

A pesar de la poca documentación y lo novedoso de la técnica, Juan le enseña a Ana algunos de los patrones más habituales de refactorización, que vienen ya integrados en la mayoría de los entornos de desarrollos más extendidos en el mercado.

Captura de pantalla del IDE NetBeans donde aparece el código de un programa y se ha seleccionado en el menú principal la opción Refactorizar.

Algunos de los patrones más habituales de refactorización, que vienen ya integrados en la mayoría de los entornos de desarrollos, son los siguientes:

Renombrar. Cambiar el nombre de un paquete, clase, método o campo, por un nombre más significativo.
Encapsular campos. Crear métodos de asignación y de consulta (getters y setters) para los campos de la clase, que permitan un control sobre el acceso de estos campos, debiendo hacerse siempre mediante el uso de estos métodos.
Sustituir bloques de código por un método. En ocasiones se observa que un bloque de código puede constituir el cuerpo de un método, dado que implementa una función por si mismo o aparece repetido en múltiples sitios. De esta forma, cada vez que queramos acceder a ese bloque de código, bastaría con invocar al método.
Modificar la extensión del código. Hacer un código más extenso si se gana en claridad o menos extenso sólo si con eso se gana eficiencia.
Reorganizar código condicional complejo. Patrón aplicable cuando existen varios if o condiciones anidadas o complejas.
Crear código común (en una clase o método) para evitar el código repetido.
Mover la clase. Mover una clase de un paquete a otro, o de un proyecto a otro. Esto implica la actualización en todo el código fuente de las referencias a la clase en su nueva localización.
Borrado seguro. Garantizar que cuando un elemento del código ya no es necesario, se borran todas la referencias a él que había en cualquier parte del proyecto.
Cambiar los parámetros del método. Permite añadir/modificar/eliminar los parámetros en un método y cambiar los modificadores de acceso.
Extraer la interfaz. Crea un nueva interfaz de los métodos public non-static seleccionados en una clase o interfaz.

Autoevaluación

Solución

Opción correcta (Retroalimentación)
Incorrecto (Retroalimentación)
Incorrecto (Retroalimentación)
Incorrecto (Retroalimentación)

1.4.- Refactorización en Eclipse

Caso práctico

Mujer joven, de pie, con camisa azul y mirando de frente.

Ana ya conoce los principios y patrones básico de refactorización, ahora Juan le va a enseñar las herramientas de Eclipse para refactorizar de forma automática y sencilla, código Java.

Los entornos de desarrollo actuales, nos proveen de una serie de herramientas que nos facilitan la labor de refactorizar nuestro código. En puntos anteriores, hemos indicado algunos de los patrones que se utilizan para refactorizar el código. Esta labor se puede realizar de forma manual, pero supone una pérdida de tiempo, y podemos inducir a redundancias o a errores en el código que modificamos.

En el Entorno de Desarrollo Eclipse, la refactorización está integrada como una función más, de las utilidades que incorpora.

A continuación se muestra el menú contextual disponible al hacer clic con el botón secundario sobre un fragmento de código en algunas versiones de Eclipse y escoger la opción Refactorizar. Aparece un menú con muchas opciones, de las que estudiaremos algunas.

Nota: el menú mostrado es contextual, por lo que la opción Refactorizar, podrá mostrar algunas opciones diferentes en función de la porción de código sobre la que sea llamado.

La mayor parte de estas funciones permanecen disponibles en las versiones más actuales de Eclipse.

A continuación se van a explorar las funciones de refactorización

1.4.1.- Renombrar

Es la opción más común, modifica el nombre a cualquier elemento (variable, atributo, método, clase…) y hace los cambios necesarios en las referencias que haya a dicho elemento en todo el proyecto.

Ejemplo: sustituir en el método main el nombre de la variable local teacher por tch. El cambio se realiza en todas sus apariciones.

Captura de pantalla de NetBeans, donde se aprecia el mecanismo de incorporación de nuevos complementos al IDE. En esta caso, se ha seleecionado el complemento Renombrar.

1.4.2.- Mover

Cambia una clase de un paquete a otro, afectando a su declaración “package” y a su localización en el disco.

Ejemplo: mover la clase ordenador del paquete clases al paquete principal.

Captura de pantalla que muestra la pestaña de mover en Eclipse.

1.4.3.- Cambiar signatura del método

Modifica la “firma” o cabecera del método. Si el método ha sido ya usado, cambiar el número o tipo de parámetros (así como el tipo de valor devuelto) provocará fallos de compilación.

Es útil para cambiar el nombre de los parámetros, o su orden (Eclipse modificará también el orden de entrada de los parámetros en todas las llamadas al método).

Ejemplo: cambiar el nombre del método y de los parámetros al método public void CambSignatura(int iParmUno, int iParmDos):

1.4.4.- Extraer variable local.

Crear una variable local inicializada con el valor de un literal (número, String…). Las referencias a esa expresión se modifican por una referencia a la variable.

1.4.5. Extraer constante

Exactamente igual que el anterior, pero genera una constante con la expresión seleccionada.
Ejemplo: sobre el método cambSig anteriormente creado, convertir el literal "Primer parametro" en una constante en el ámbito de la clase.

1.4.6. Convertir variable local en atributo.

A veces se definen variables locales dentro de un método que luego resultan ser relevantes en el ámbito de la clase, por tanto debe ser considerada un atributo de la clase.

1.4.7. Extraer método.

Convierte el código seleccionado en un método, útil en código que es reutilizado en varios sitios del programa. También puede servir para aligerar un método que es demasiado largo.

Eclipse solo solicita el nombre del método pero descubre automáticamente los parámetros y tipo de retorno necesarios.

1.4.8. Incorporar

Hace lo contrario que los “Extract”: elimina una declaración de variable, método o constante y coloca su valor (en el caso de variables y constantes) o su código (en el caso de métodos) en aquellos lugares en que se referenciaba a esa variable, método o constante que ya no existirán.

Es muy útil cuando se comprueba que el contenido de una variable o constante se va a usar una sola vez y por tanto no merece la pena almacenarlo, sino que queda más limpio el código en una línea. También cuando se observa que un método sólo se llama una o dos veces, por lo que no merece la pena aislar ese código en un método.

1.4.9. Autoencapsular atributo.

Convierte una variable de clase en privada y genera los métodos Get y Set públicos para acceder a la misma. Opción también disponible desde el menú código fuente que se verá a continuación.

1.5.- Analizadores de código.

Caso práctico

María se va a centrar el el uso de analizadores de código con la ayuda de Carlos. Carlos no sabe lo que son los analizadores de código ni para qué sirven.

Cada IDE incluye herramientas de refactorización y analizadores de código. En el caso se software libre, existen analizadores de código que se pueden añadir como complementos a los entornos de desarrollo.

El análisis estático de código, es un proceso que tiene como objetivo, evaluar el software, sin llegar a ejecutarlo. Esta técnica se va a aplicar directamente sobre el código fuente, para poder obtener información que nos permita mejorar la base de código. Si el analizador considera que nuestro código fuente tiene una estructura mejorable, nos lo indicará y también nos comunicará la mejora a realizar. Por lo tanto, el uso de analizadores de código proporciona información sobre algunos aspectos a considerar en la refactorización de los programas.

Las principales funciones de los analizadores es encontrar partes del código que puedan reducir el rendimiento, provocar errores en el software, tener una excesiva complejidad, complicar el flujo de datos, crear problemas de seguridad.

El análisis se realiza siguiendo una serie de reglas predefinidas.

Un ejemplo es PMD, una herramienta para Java que basa su funcionamiento en detectar patrones, que son posibles errores en tiempo de ejecución, código que no se puede ejecutar nunca porque no se puede llegar a él, código que puede ser optimizado, expresiones lógicas que pueden ser simplificadas, malos usos del lenguaje, etc.

Otro analizador de código disponible en el mercado es Sonarcube, herramienta Open-Source de análisis de calidad del código disponible para gran cantidad de lenguajes de programación.

1.5.1.- Instalación de PMD

Los analizadores de código estático, 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 vamos a instalar el plug-in para PMD. Para ello lo descargamos de este enlace:

http://plugins.netbeans.org/plugin/57270/easypmd

Cómo ya vimos en la unidad anterior, para instalar dicho plugin, en NetBeans vamos a Tools/plugins/Downloaded.

Pulsamos sobre “Add plugins”

Y buscamos el fichero que nos hemos descargado, lo abrimos y lo instalamos. Ya vimos en la unidad 3 como se hacía.

Y reiniciamos NetBeans.

Vamos a Plugins/Installed:

y en “Search” ponemos “PMD”:

Y nos aseguramos que ha quedado activado. Si no es así, lo hacemos.

1.5.2.- Configuración.

Como se indicó en el apartado anterior, PMD es un analizador de código estático, capaz de detectar automáticamente un amplio rango de defectos y de inseguridades en el código. PMD se centra en detectar defectos de forma preventiva.

Una vez que tenemos desarrollado nuestro código, si queremos analizarlo con PMD, y obtener el informe del análisis, primero hay que pulsa en el menú Tools/Options:

y en "EasyPMD", en la pestaña "Rulesets":

Se indicas las reglas que están activadas. Puedes activas más reglas. Para ello, pinchas en "Add standard" y añades las reglas que creas conveniente. Por ejemplo, vamos a añadir la regla "Naming". La seleccionamos y aceptar.

Y veremos que esta regla se queda incluida.

Esta regla analiza, por ejemplo, que el nombre de un método no empieza por la primera letra en mayúscula, variables que no se usan o nombres muy cortos.

Mientras se analiza el código, el plug-in mostrará una barra de progreso en la esquina inferior derecha. El informe producido contiene la localización, el nombre de la regla que no se cumple y la recomendación de cómo se resuelve el problema.

El informe PMD, nos permite navegar por el fichero de clases y en la línea donde se ha detectado el problema. En el número de línea, veremos una marca PMD. Si se posiciona el ratón encima de ella, veremos un tooltip con la descripción del error.

Para probarlo, crea un proyecto en NetBeans con este código (pulsa aquí si quieres descargar dicho proyecto:

/*
* To change this license header, choose License Headers in Project Properties.
* To change this template file, choose Tools | Templates
* and open the template in the editor.
*/
package practicapmd;

public class PracticaPMD {

public static void main(String[] args) {
int a;

int altura = 89;
if (altura > 89) {
System.out.println("Eres muy alto");
}
PracticaPMD ejemPMD = new PracticaPMD();
ejemPMD.MetodoDobleReturn();
metodo();
}

static void metodo() {

}

public boolean MetodoDobleReturn() {
int iValor = 10;
if (iValor == 5) 
return false;
else {
return true;
}
}

}

Pulsa sobre el menú "Windows" y sobre "Action Items"

Y te da un informe de las reglas que no cumple tú código. En el ejemplo te avisa de:

Un error muy grave y es poner a un método un nombre que empieza por una letra mayúscula.
Un error leve que es el nombre de la variable "a". Un nombre muy corto.

Así podemos ir añadiendo más reglas. Cómo, por ejemplo, que me avise si alguna estructura de control no tiene llaves, aunque tenga una sola instrucción. Para ello, hay que añadir la regla: "braces".

Para ello, pulsamos en el menú Tools/Options:

y en "EasyPMD", en la pestaña "Rulesets":

Pulsamos sobre "Add Standard" y añadimos la regla:

Aceptamos y tendremos esa regla añadida:

Damos a Ok.

Y veremos como me avisa que hay un if que no tiene llaves:

Ahora añade la regla "Design" y veras como te avisa en el informe que tienes un método vacío.

Información del Action Items:

2.- Control de versiones.

Caso práctico

Juan y María están implementando la mayor parte de la aplicación. Continuamente está modificando el código generado, bien para mejorar algunos aspecto, o por qué han refactorizado. Hay diferentes versiones de una misma clase, de un mismo método. ¿Qué ocurre si se borra accidentalmente algún fichero? ¿Qué pasa si María modifica una clase que necesita Juan?

Cuando estamos desarrollando software, el código fuente está cambiando continuamente, bien por el propio desarrollo o por el mantenimiento a que se ve sometido. Además los proyectos en ocasiones se desarrollan por fases o se hacen diferentes entregas al cliente. Todos estos factores hacen necesario un sistema de control de versiones.

Las ventajas de utilizar un sistema de control de versiones son múltiples. Un sistema de control de versiones bien diseñado facilita al equipo de desarrollo su labor, permitiendo que varios programadores trabajen en el mismo proyecto (incluso sobre los mismo archivos) de forma simultánea, permitiendo gestionar los conflictos que se puedan producir por actualizaciones simultáneas sobre el mismo código. Las herramientas de control de versiones proveen de un sitio central donde almacenar el código fuente de la aplicación, así como el historial de cambios realizados a lo largo de la vida del proyecto.

También permite a los desarrolladores volver a versiones estables previas del código fuente si es necesario.

Una versión, desde el punto de vista de la evolución, se define como la forma particular de un objeto en un instante o contexto dado. Se denomina revisión, cuando se refiere a la evolución en el tiempo.

Pueden coexistir varias versiones alternativas en un instante dado y hay que disponer de un método, para designar las diferentes versiones de manera organizada.

Existen distintas alternativas de control de versiones de código abierto, GIT, CVS, Subversion, Mercurial... En ocasiones podrán ser motivo de gestión proyectos software en desarrollo o simplemente conjuntos de archivos de algún otro uso.

Un repositorio interesante para la gestión de proyectos es Bitbucket, está basado en Git y dispone de una versión gratuita para equipos de 5 personas. Ideal para gestionar el proyecto fin de ciclo.

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

2.1.- Tipos de herramientas de control de versiones.

e acuerdo al modo de organizar la información, se pueden clasificar las herramienta de control de versiones como:

- Sistemas locales: se trata del control de versiones donde la información se guarda en diferentes directorios en función de sus versiones. Toda la gestión recae sobre el responsable del proyecto y no se dispone de herramientas que automaticen el proceso. Es viable para pequeños proyectos donde el trabajo es desarrollado por un único programador.

- Sistemas centralizados: responden a una arquitectura cliente-servidor. Un único equipo tiene todos los archivos en sus diferentes versiones, y los clientes replican esta información en sus entornos de trabajo locales. El principal inconveniente es que el servidor es un dispositivo crítico para el sistema ante posibles fallos.
- Sistemas distribuidos: en este modelo cada sistema hace con una copia completa de los ficheros de trabajo y de todas sus versiones. El rol de todos los equipos es de igual a igual y los cambios se pueden sincronizar entre cada par de copias disponibles. Aunque técnicamente todos los repositorios tienen la posibilidad de actuar como punto de referencia; habitualmente funcionan siendo uno el repositorio principal y el resto asumiendo un papel de clientes sincronizando sus cambios con éste.

2.2.- Estructura de herramientas de control de versiones.

Caso práctico

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.

Imagen que muestra dos rectángulos, uno azul y otro verde. En el rectángulo azul se muestra un grafo con la estructura de archivos y directorios de una aplicación, Para gestionar las diferentes versiones, se aplican las operaciones add, edit, borrar, y abort, que están representadas mediante fechas. Si se ejecuta un commit, todos los elementos de la aplicación se almacen en el repositorio (cuadrado verde donde está el CVSROOT y todas las versiones almacenadas de la aplicación). Si queremos obtener una versión almacenada en el repositorio, se realiza la operación Checkout, y recuperariamos los almacenado en el repositorio.

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 código 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 más personas pueden modificar un mismo fichero sin que se pierdan los trabajos de ninguna. Además, las operaciones más habituales son muy sencillas de usar.

CVS utiliza una arquitectura cliente-servidor: un servidor guarda la versión 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. Típicamente, cliente y servidor conectan utilizando Internet, pero cliente y servidor pueden estar en la misma máquina. El servidor normalmente utiliza un sistema operativo similar a Unix, mientras que los clientes CVS pueden funcionar en cualquier de los sistemas operativos más difundidos.

Los clientes pueden también comparar diferentes versiones de ficheros, solicitar una historia completa de los cambios, o sacar una "foto" histórica del proyecto tal como se encontraba en una fecha determinada o en un número de revisión determinado. Muchos proyectos de código abierto permiten el "acceso de lectura anónimo", significando que los clientes pueden sacar y comparar versiones sin necesidad de teclear una contraseña; solamente el ingreso de cambios requiere una contraseña en estos escenarios. Los clientes también pueden utilizar el comando de actualización con el fin de tener sus copias al día con la última versión 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 algún ordenador.
Módulo: en un directorio especifico del repositorio. Puede identificar una parte del proyecto o ser el proyecto por completo.
Revisión: es cada una de las versiones parciales o cambios en los archivos o repositorio completo. La evolución del sistema se mide en revisiones. Cada cambio se considera incremental.
Etiqueta: información textual que se añada a un conjunto de archivos o a un módulo completo para indicar alguna información importante.
Rama: revisiones paralelas de un módulo para efectuar cambios sin tocar la evolución principal. Se suele emplear para pruebas o para mantener los cambios en versiones antiguas.

Algunos de los servicios que típicamente proporcionan son:

Creación de repositorios. Creación del esqueleto de un repositorio sin información inicial del proyecto.
Clonación de repositorios. La clonación crea un nuevo repositorio y vuelca la información de algún otro repositorio ya existente. Crea una réplica.
Descarga de la información del repositorio principal al local. Sincroniza la copia local con la información disponible en el repositorio principal.
Carga de información al repositorio principal desde el local. Actualiza los cambios realizados en la copia local en el repositorio principal.
Gestión de conflictos. En ocasiones, los cambios que se desean consolidar en el repositorio principal entran en conflicto con otros cambios que hayan sido subidos por algún otro desarrollador. Cuando se da esta situación, las herramientas de control de versiones tratan de combinar automáticamente todos los cambios. Si no es posible sin pérdida de información, muestra al programador los conflictos acontecidos para que sea éste el que tome la decisión de como combinarlos.
Gestión de ramas. Creación, eliminación , integración de diferencias entre ramas, selección de la rama de trabajo.
Información sobre registro de actualizaciones.
Comparativa de versiones. Genera información sobre las diferencias entre versiones del proyecto.

Las órdenes que se pueden ejecutar son:

checkout: obtiene un copia del trabajo para poder trabajar con ella.
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.

2.2.1.- Repositorio.

Caso práctico

Juan le ha explicado a Ana la los fundamentos del control de versiones, pero quiere profundizar más 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 información y datos de un proyecto.

El repositorio es un almacén general de versiones. En la mayoría 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 información de la evolución del sistema, ya que, aparte de los datos en sí mismo, también almacena información sobre las versiones, temporización, 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 deberán almacenar todos los ficheros de los proyectos, que puedan ser accedidos de forma simultánea por varios desarrolladores.

Cuando usamos una sistema de control de versiones, trabajamos de forma local, sincronizándonos con el repositorio, haciendo los cambios en nuestra copia local, realizado el cambio, se acomete el cambio en el repositorio. Para realizar la sincronización, 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 características de versionado. El IDE escanea nuestro proyectos abiertos y si contienen directorios CVS, el estado del archivo y la ayuda-contextual se activan automáticamente para los proyectos de versiones CVS.

Autoevaluación

Solución

Incorrecto (Retroalimentación)
Incorrecto (Retroalimentación)
Opción correcta (Retroalimentación)

2.2.2.- Gestión de versiones y entregas.

Caso práctico

María ha desarrollado varias versiones del módulo de reservas de la aplicación de Gestión Hotelera. Le explica a Carlos como ha sido la evolución de cada versión del módulo, desde la primera versión, hasta la versión actual, que ella cree definitiva.

Las versiones hacen referencia a la evolución de un único elemento, dentro de un sistema software. La evolución puede representarse en forma de grafo, donde los nodos son las versiones y los arcos corresponden a la creación de una versión a partir de otra ya existente.

Grafo de evolución simple: las revisiones sucesivas de un componente dan lugar a una simple secuencia lineal. Esta evolución no presenta problemas en la organización del repositorio y las versiones se designan mediante números 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 numeración de las versiones requerirá dos niveles. El primer número designa la variante (línea de evolución) y el segundo la versión particular (revisión) a lo largo de dicha variante.

La terminología que se usa para referirse a los elementos del grafo son:

Tronco (trunk): es la variante principal.
Cabeza (head): es la última versión del tronco.
Ramas (branches): son la variantes secundarias.
Delta: es el cambio de una revisión respecto a la anterior.

Propagación de cambios: cuando se tienen variantes que se desarrollan en paralelo, suele ser necesario aplicar un mismo cambio a varias variantes.

Fusión de variantes: en determinados momentos puede dejar de ser necesario mantener una rama independiente. En este caso se puede fundir con otra (MERGE).

Técnicas de almacenamiento: como en la mayoría de los casos, las distintas versiones tienen en común gran parte de su contenido, se organiza el almacenamiento para que no se desaproveche espacio repitiendo los datos en común de varias versiones.

Deltas directos: se almacena la primera versión completa, y luego los cambios mínimos necesarios para reconstruir cada nueva versión a partir de la anterior.
Deltas inversos: se almacena completa la última versión del tronco y los cambios necesarios para reconstruir cada versión 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 sección del conjunto con los números de versiones que corresponde.

En cuanto a la gestión 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 planificación de la entrega se ocupa de cuándo emitir una versión del sistema como una entrega. La entrega está compuesta por el conjunto de programas ejecutables, los archivos de configuración que definan como se configura la entrega para una instalación particular, los archivos de datos que se necesitan para el funcionamiento del sistema, un programa de instalación para instalar el sistema en el hardware de destino, documentación electrónica y en papel, y, el embalaje y publicidad asociados, diseñados para esta entrega Actualmente los sistemas se entregan en discos ópticos (CD o DVD) o como archivos de instalación descargables desde la red.

2.3.- Herramientas de control de versiones.

Caso práctico

María 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.

Captura de pantalla del IDE NetBeans, donde aparece resaltada la opción del menú contextual, que hay que seleccionar para importar el repositorio CVS, que es una herramienta para control de versiones que usa NetBeans.

Durante el proceso de desarrollo de software, donde todo un equipo de programadores están colaborando en el desarrollo de un proyecto software, los cambios son continuos. Es por ello necesario que existan en todos los lenguajes de programación y en todos los entornos de programación, 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 código abierto ampliamente utilizada en numerosas organizaciones. Subversion es el sucesor natural de CVS, está rápidamente integrándose en los nuevos proyectos Java, gracias a sus características que lo hacen adaptarse mejor a las modernas prácticas de programación 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 difusión 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 código fuente, recolección de datos, informes y seguimiento de proyectos, y está destinado a proyectos de colaboración de desarrollo de software.
Darcs: es un sistema de gestión de versiones distribuido. Algunas de sus características son: la posibilidad de hacer commits locales (sin conexión), cada repositorio es una rama en sí misma, independencia de un servidor central, posibilidad de renombrar ficheros, varios métodos de acceso como local, ssh, http y ftp, etc.
Git: esta herramienta de control de versiones, diseñada por Linus Torvalds.
Mercurial: esta herramienta funciona en Linux, Windows y Mac OS X, Es un programa de línea 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 ramificación e integración. Es una herramienta que incluye una interfaz web para su configuración y uso.

Autoevaluación

Solución

Incorrecto (Retroalimentación)
Incorrecto (Retroalimentación)
Incorrecto (Retroalimentación)
Opción correcta (Retroalimentación)

Debes conocer

También debes visitar el siguiente enlace donde se puede ver la guía de uso de subversión en Netbeans. Está en inglés pero es conveniente que le eches un vistazo para conocer cómo funciona Subversion.

Guía de uso de Subversion en Netbeans.

Autoevaluación

Solución

Opción correcta (Retroalimentación)
Incorrecto (Retroalimentación)
Incorrecto (Retroalimentación)

Caso práctico

Mujer joven, de pie, con camisa azul y mirando de frente.

Juan le va a enseñar 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.

2.4.- Planificación de la gestión de configuraciones.

Caso práctico

Imagen de cinco personas sentadas en una mesa, donde hay un proyector funcionando y una mujer explicando algo, mirando hacia una pantalla.

El equipo de desarrollo de BK Programación decide reunirse para planificar la gestión de configuraciones, ya que la aplicación de Gestión Hotelera es amplia y compleja, y continuamente se están diseñando nuevos módulos, clases o métodos.

La Gestión de Configuraciones del software (GCS) es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida.

La planificación de las Gestión de Configuraciones del software, está regulado en el estándar IEEE 828.

Cuando se habla de la gestión de configuraciones, se está haciendo referencia a la evolución de todo un conjunto de elementos. Una configuración es una combinación de versiones particulares de los componentes que forman un sistema consistente. Desde el punto de vista de la evolución en el tiempo, es el conjunto de las versiones de los objetos componentes en un instante dado.

Una configuración puede cambiar porque se añaden, eliminan o se modifican elementos. También puede cambiar, debido a la reorganización de los componentes, sin que estos cambien.

Como consecuencia de lo expuesto, es necesario disponer de un método, que nos permita designar las diferentes configuraciones de manera sistemática y planificada. De esta forma se facilita el desarrollo de software de manera evolutiva, mediante cambios sucesivos aplicados a partir de una configuración inicial hasta llegar a una versión final aceptable del producto.

La Gestión de Configuraciones de Software se va a componer de cuatro tareas básicas:

Identificación. Se trata de establecer estándares de documentación y un esquema de identificación de documentos.
Control de cambios. Consiste en la evaluación y registro de todos los cambios que se hagan de la configuración software.
Auditorías de configuraciones. Sirven, junto con las revisiones técnicas formales para garantizar que el cambio se ha implementado correctamente.
Generación 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.

2.5.- Gestión del cambio.

Caso práctico

Mujer de pelo corto y chaqueta negra mirando de frente.

Para gestionar el control de versiones de forma centralizada, Ada va a supervisar los cambios de versión que el equipo de Juan y de María están efectuando de forma independiente. Ada va a realizar una gestión del cambio centralizada y organizada.

Esquema donde se aprecian las diferentes partes que establece el control de cambios. Nos encontramos con los cuadrados verdes que indican diferentes estados en los que se encuentra el control de cambios. Partimos de “Esperando desarrollo”, Si se inicia el desarrollo, pasamos a “En Desarrollo” si hay anulación, salimos del control de cambios. En el estado “En desarrollo”, podemos pasar a “En revisión” o anular el desarrollo y pasar al estado anterior, no habiendo cambio. Si se termina el desarrollo, pasamos a “En revisión”, si se acepta la revisión, pasamos a “Esperando integración” o si se rechaza,vovemosa “En desarrollo”. Una vez revisado un cambio, se pasa a “Esperando integración”, que si acepta el cambio, lo pasa a “En integración” y de ahí se a “Completado” el cambio. Si en algún paso, ser rechaza los cambios, volvemos “En Desarrollo”.

Las herramientas de control de versiones no garantizan un desarrollo razonable, si cualquier componente del equipo de desarrollo de una aplicación puede realizar cambios e integrarlos en el repositorio sin ningún tipo de control. Para garantizar que siempre disponemos de una línea base para continuar el desarrollo, es necesario aplicar controles al desarrollo e integración de los cambios. El control de cambios es un mecanismo que sirve para la evaluación y aprobación de los cambios hechos a los elementos de configuración del software.

Pueden establecerse distintos tipos de control:

Control individual, antes de aprobarse un nuevo elemento.
Cuando un elemento de la configuración está bajo control individual, el programador responsable cambia la documentación cuando se requiere. El cambio se puede registrar de manera informal, pero no genera ningún documento formal.
Control de gestión u organizado, conduce a la aprobación de un nuevo elemento.
Implica un procedimiento de revisión y aprobación para cada cambio propuesto en la configuración. Como en el control individual, el control a nivel de proyecto ocurre durante el proceso de desarrollo pero es usado después de que haya sido aprobado un elemento de la configuración software. El cambio es registrado formalmente y es visible para la gestión.
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 evalúa por un Comité de Control de Cambios, el cuál aprueba la modificaciones de la configuración software.

Autoevaluación

Solución

Incorrecto (Retroalimentación)
Incorrecto (Retroalimentación)
Incorrecto (Retroalimentación)
Opción correcta (Retroalimentación)

3.- Documentación.

Caso práctico

Juan y María saben de la importancia de tener documentado el código y todo el proceso de desarrollo de software. Al mismo tiempo que codifican y refactorizan, dejan constancia documental de lo que van haciendo. Como están desarrollando con Netbeans, y con el objetivo de facilitar su trabajo de documentación, van a utilizar JavaDoc. Ana y Antonio consiguen entender el funcionamiento de la aplicación, y la función de cada método, gracias a los comentarios que insertan en el código los dos programadores principales.

El proceso de documentación de código, es uno de los aspectos más importantes de la labor de un programador. Documentar el código nos sirve para explicar su funcionamiento, punto por punto, de forma que cualquier persona que lea el comentario, puede entender la finalidad del código.

En la actualidad, el desarrollo rápido de aplicaciones, en muchos casos, va en detrimento de una buena documentación del código. Si el código no está documentado, puede resultar bastante difícil de entender, y por tanto de solucionar errores y de mantenerlo.

La labor de documentación es fundamental para la detección de errores y para su mantenimiento posterior, que en muchos casos, es realizado por personas diferentes a las que intervinieron en su creación. Hay que tener en cuenta que todos los programas tienen errores y todos los programas sufren modificaciones a los largo de su vida.

La documentación añade explicaciones de la función del código, de las características de un método, etc. Debe tratar de explicar todo lo que no resulta evidente. Su objetivo no es repetir lo que hace el código, sino explicar por qué se hace.

La documentación explicará cuál es la finalidad de un clase, de un paquete, qué hace un método, 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 podría mejorar en el futuro, etc.

Para saber más

El siguiente enlace nos muestra el estilo de programación a seguir en Java, así como la forma de documentar y realizar comentarios de un código. (En inglés)

Documentación y comentarios en Java

3.1.- Uso de comentarios.

Caso práctico

Carlos está aprendiendo muchas cosas con María. Sin embargo hay algunos métodos y clases que ha implementado María, y que no logra entender. María le comenta que va a incluir comentarios en su código, y le va a enseñar la forma correcta de hacerlo.

Caso práctico

Hombre de pie mirando de frente.

Juan le explica a María, que para documentar el software, existen diferentes formas de hacerlo y distintas herramientas en el mercado que automatizan la tarea de documentación.

Captura de pantalla donde se muestran el código de una aplicación Java, donde aperecen resaltados los tipos de comentarios que puede tener: comentarios Javadoc, comentarios de una línea y comentario multilínea.

Uno de los elementos básicos para documentar código, es el uso de comentarios. Un comentario es una anotación que se realiza en el código, pero que el compilador va a ignorar, sirve para indicar a los desarrolladores de código diferentes aspectos del código que pueden ser útiles.

Es la primera alternativa que surge para documentar código. Con los comentarios, documentamos la funcionalidad de una línea de código, de un método o el comportamiento de una determinada clase.

En principio, los comentarios tienen dos propósitos diferentes:

Explicar el objetivo de las sentencias. De forma que el programador o programadora, sepa en todo momento la función de esa sentencia, tanto si lo diseñaron como si son otros los que quieren entenderlo o modificarlo.
Explicar qué realiza un método, o clase, no cómo lo realiza. En este caso, se trata de explicar los valores que va a devolver un método, pero no se trata de explicar cómo se ha diseñado.

En el caso del lenguaje Java, C# y C, los comentarios, se implementan de forma similar. Cuando se trata de un comentario de una sola línea, se usan los caracteres // seguidos del comentario. Para comentarios multilínea, los caracteres a utilizar son /* y */, quedaría: /* comentario-multilínea */.

No es obligatorio, pero en muchas situaciones es conveniente, poner los comentarios al principio de un fragmento de código que no resulta lo suficientemente claro, a la largo de bucles, o si hay alguna línea de código que no resulta evidente y pueda llevarnos a confusión.

Insertando comentario en el código más difícil de entender, y utilizando la documentación generada por alguna de las herramientas citadas anteriormente, se genera la suficiente información para ayudar a cualquier nuevo programador o programadora.

Hay que tener en cuenta, que si el código es modificado, también se deberán modificar los comentarios.

3.2.- Documentación de clases.

Caso práctico

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 aplicación como para entender su funcionamiento, tener documentadas las clases.

Captura de pantalla que muestra el resultado de documentar una clase con JavaDoc. Aparece el constructor de la clase documentado, y varios métodos de la misma clase.

Existen diferentes herramientas que permiten automatizar, completar y enriquecer nuestra documentación. Podemos citar JavaDoc, SchemeSpy y Doxygen, que producen una documentación actualizada, precisa y utilizable en línea, incluyendo además, con SchemeSpy y Doxygen, modelos de bases de datos gráficos y diagramas.

Las clases que se implementan en un aplicación, deben de incluir comentarios. Al utilizar un entorno de programación para la implementación de la clase, debemos seguir una serie de pautas, muchas de las cuales las realiza el IDE de forma trasparente, en el diseño y documentación del código.

Los entornos de programación que implementa Java, como Eclipse o Netbeanss, incluyen una herramienta que va a generar páginas HTML de documentación a partir de los comentarios incluidos en el código fuente. La herramienta ya se ha indicado en los puntos anteriores, y es JavaDoc.

Para que JavaDoc pueda generar las páginas HTML es necesario seguir una serie de normas de documentación en el código fuente, estas son:

Los comentarios son obligatorios con JavaDoc, y se deben incorporar al principio de cada clase, al principio de cada método y al principio de cada variable de clase. Se escriben empezando por /** y terminando con */ , estos comentarios pueden ocupar varias líneas. Todos los comentarios hechos con // y /*comentario*/ no se incluirán en la documentación de la clase.
Los comentarios pueden ser a nivel de clase, a nivel de variable y a nivel de método.
La documentación se genera para métodos public y protected.
Se puede usar tag para documentar diferentes aspectos determinados del código, como parámetros.

Con el uso de los entornos de desarrollo, las etiquetas se añaden de forma automática, estableciendo el @author y la @version de la clase de forma transparente al programador-programadora. También se suele añadir la etiqueta @see, que se utiliza para referenciar a otras clases y métodos.

Dentro de la la clase, también se documentan los constructores y los métodos.

Existe una serie de etiquetas que fijan como se presentará la información en la documentación resultante JavaDoc. En la url https://en.wikipedia.org/wiki/Javadoc aparece una colección de palabras reservadas (etiquetas) definidas en Javadoc. A continuación se muestran algunas de las más utilizadas.

Etiqueta y parámetros	Uso	Asociada a
@author nombre	Nombre del autor (programador)	Clase, interfaz
@version numero-version	Comentario con datos indicativos del número de versión.	Clase, interfaz
@since numero-version	Fecha desde la que está presente la clase.	Clase, interfaz, campo, método.
@see referencia	Permite crear una referencia a la documentación de otra clase o método.	Clase, interfaz, campo, método.
@param seguido del nombre del parámetro	Describe un parámetro de un método.	Método.
@return descripción	Describe el valor devuelto de un método.	Método.
@exception clase descripción @throws clase descripción	Comentario sobre las excepciones que lanza.	Método.
@deprecated descripción	Describe un método obsoleto.	Clase, interfaz, campo, método.

Los campos de una clase, también pueden incluir comentarios, aunque no existen etiquetas obligatorias en JavaDoc.

Caso práctico

Mujer de pie, explicando el código de un programa, que está proyectado sobre una pantalla blanca.

Para documentar el código, el equipo de desarrollo de BK Programación, ha decidido utilizar JavaDoc, por lo que todos los componentes del equipo de desarrollo, debe familiarizarse con la herramienta.

Autoevaluación

Solución

Incorrecto (Retroalimentación)
Incorrecto (Retroalimentación)
Opción correcta (Retroalimentación)

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:

En el IDE NetBeans elegimos Herramientas - CVS - Extraer. El asistente para extraer el modulo se nos abrirá.

En el primer panel del asistente, se introduce la localización del repositorio definido con

CVSROOT. El IDE soporta diferentes formatos de CVSROOT, dependiendo de si el repositorio es local o remoto, y del método utilizado para conectarnos a él.

Métodos de conexión a `CVSROOT`
Método	Descripción	Ejemplo
`pserver`	Contraseña de servidor remoto.	`:pserser:username@hotsname:/repository_path`
`ext`	Acceso usando Remote Shell (RSH) o Secure Shell (SSH).	`:ext:username@hostname:/repository_path`
`local`	Acceso a un repositorio local.	`:local:/repository_path` `(requiere un CVS externo ejecutable)`
`fork`	Acceso a un repositorio local usando un protocolo remoto.	`:fork:/repository_path` `(requiere un CVS externo ejecutable)`

En el panel de Módulos a extraer del asistente, especificamos el módulo que queremos extraer, en el campo Módulo. Si no sabemos el nombre del módulo, podemos extraerlo haciendo clic en el botón 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:
En el campo de texto, ponemos el nombre del Módulo que queremos extraer. Podemos usar el botón Examinar, para buscar aquellos módulos disponibles.
En el campo Carpeta local, pondremos la ruta de nuestro ordenador donde queremos extraer los archivos. Pulsaremos el botón 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 después de que haya sido versionado con el repositorio CVS.

Para importar un proyecto a un repositorio:

Desde la ventana de proyectos, seleccionamos un proyecto que no este versionado, y elegimos Equipo - CVS - Importar al depósito. Se abrirá el asistente de importación CVS.
En el panel Raíz CVS del asistente, se especifica la localización del repositorio definido como CVSROOT. Dependiendo del método usado, necesitaremos utilizar más información, como la contraseña o configuración del proxy, para conectarnos a un repositorio remoto.
En Carpeta a importar, se especifica el directorio local donde queremos colocar el repositorio.
En el área de texto Importar mensaje, pondremos una descripción del proyecto que estamos importando.
Se especifica la localización del repositorio donde queremos importar el proyecto, escribiendo la ruta en Carpeta del depósito. De forma alternativa, se puede hacer clic en el botón Examinar para ir a una localización especifica en el repositorio. Al hacer clic en el botón Terminar se inicia la importación. El IDE copiara los ficheros del proyecto en el repositorio.

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 aplicación, si queremos gestionar el control de versiones, podemos utilizar cualquiera de los tres.

Captura de pantalla del menú de NetBeans, donde podemos seleccionar entre los tres clientes de control de versiones integrado en el entorno de desarrollo: CVS, Mercurial y Subversion.

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 código. La configuración de CVS puede suponer unos cinco minutos, que dentro del tiempo de desarrollo de una aplicación, es un tiempo despreciable. Sin embargo, el uso de CVS en NetBeans, nos va a gestionar las distintas versiones del código que se desarrollen y nos va a evitar pérdidas de datos y de código.

Para utilizar CVS, es necesario la instalación de un cliente CVS, sin embargo, NetBeans nos va a evitar esta instalación, ya que incorpora un cliente CVS en Java.

CVS se puede utilizar con NetBeans de tres formas:

Desde la línea de comando CVS, donde se escribirán los comandos CVS y de esta forma se interactuará con el repositorio.
Si CVS está incorporado a NetBeans, dispondremos de un conjunto de clases Java que imitan los comandos clásicos de CVS.
Con fórmulas de línea de comandos CVS genéricas 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 están parametrizadas, con la lógica 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 lógica interna de CVS. Nos evitamos tener que conocer todos los parámetros 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 número de versión independiente, todo el repositorio tiene un único número de versión que identifica un estado común de todos los archivos del repositorio en un instante determinado.

Subversion puede acceder al repositorio a través 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 colaboración. Se puede progresar más rápidamente 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 guía de Subversion que te sugerimos en la unidad de trabajo.

MERCURIAL

Mercurial es un sistema de control de versiones que utiliza sobre todo la línea 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 de un servidor, gestión robusta de archivos de texto y binarios, y capacidades avanzadas de ramificación e integración.

Anexo III.- GIT

En un proyecto de trabajo colaborativo, cada miembro del equipo realiza las tareas que le han sido asignadas, pero al terminar cada uno de ellos, habrá que preguntarse:

¿Cómo se integran todas las partes?.
Si hay errores o cambios, ¿cómo se actualizan los nuevos cambios?.
Si hay una nueva versión, ¿cómo se gestionan los conjuntos de módulos compatibles con cierta versión?, ¿cómo se recuperan versiones anteriores?, ¿cómo se fusionan versiones? ...

En el punto 2.3 hemos nombrado las diferentes herramientas de control de versiones. Vamos a ver en este anexo, en detalle, la herramienta "GIT".

Algunas de las características de GIT son:

Gratis, de código abierto.
Muy popular, disponible en múltiples plataformas.
Distribuido. Las diferentes réplicas de los repositorios tienen una relación de igual a igual. Esta es una consideración técnica, en la práctica una de ellas suele adquirir el rol de repositorio principal.
Basado en changesets. Si varios componentes del proyecto han cambiado respecto a la última versión, todos ellos son volcados al repositorio de una vez, esta entrega se considera atómica.
No bloqueante. Es posible que varios repositorios locales estén trabajando de forma simultánea sobre los mismos componentes, posteriormente habrá que integrar las modificaciones efectuadas en todos ellos para obtener un versionado común.

a.- Terminología

Algunos de los términos de uso habitual en GIT son:

Repositorio: base de datos con las sucesivas versiones. Un repositorio podrá estar compuesta de diversas líneas de desarrollo o ramas. Típicamente habrá un repositorio común y tantos repositorios locales como participantes en la actividad colaborativa.
Rama master o trunk: rama principal del desarrollo.
Rama (Branch): línea de desarrollo paralela a la rama master. Podría recoger trabajos para diferentes clientes.
Área de trabajo: ficheros sobre los que trabaja el programador.
Commit: confirmación de una nueva versión (de la copia de trabajo al repositorio local).
Checkout: (re)generación de la copia de trabajo a partir de la información del repositorio local.
Fusión (Merge): acumular cambios en una misma versión . Permite combinar diferentes branchs en el repositorio local.
Comentario: cada commit deberá documentar sus efectos y motivaciones.
Push: actualización del repositorio remoto con la información del repositorio local.
Fetch: actualización del repositorio local con la información del repositorio remoto.
Pull: actualización del repositorio local y del área de trabajo con la información del repositorio remoto.

b.- Escenario de trabajo con GIT.

En un proyecto colaborativo coordinado con GIT, un escenario típico de trabajo sería el siguiente.

En la figura se puede ver una máquina remota donde se encuentra el repositorio principal o remoto, sitio donde se pone en común todo el trabajo del conjunto de integrantes del equipo. Cada desarrollador tendrá su propio espacio de trabajo, en la figura se muestra una única máquina local.

Inicialmente, el entorno local tendrá un repositorio que será una réplica idéntica del repositorio remoto. Además el programador dispondrá de su área de trabajo, donde irá actualizando el código. Cuando unos cambios cobran suficiente entidad como para constituir una versión, éstos son guardados en el repositorio local. Finalmente, si el programador desea poner en común con los otros miembros del proyecto sus cambios, enviará sus actualizaciones desde el repositorio local al común.

c.- Flujo de trabajo.

El flujo de trabajo normal del programador consistirá en las siguientes actuaciones:

Modificar el área de trabajo. Actualizando el contenido de los ficheros del proyecto o creando/eliminando algunos de ellos.
Seleccionar aquellos ficheros que se desea formen parte de la nueva versión del proyecto. Los ficheros que no sean seleccionados, aunque hayan sido cambiados no serán guardados en el repositorio.
Comprobar cambios. Habrá que cerciorarse que los cambios introducidos en el proyecto son los deseados.
Salvar las modificaciones introducidas en el área de trabajo al repositorio local.

Los cuatro puntos anteriores se podrán repetir tantas veces como sea necesario. A continuación habrá que:

Conseguir los cambios de otros compañeros. Es muy probable que en el repositorio común existan actualizaciones que haya introducido algún otro colaborador, por lo que se hace necesario combinar esos cambios con los que queremos compartir nosotros.
Actualizar el repositorio común desde el local para compartir nuestros cambios.

d.- Resumen de comandos GIT.

A continuación se muestran algunos de los comandos más utilizados en GIT.

- init
  Crea un nuevo repositorio en el directorio inicialmente vacío. Se almacena en el directorio oculto .git.

- clone
  Crea un nuevo repositorio, copia de uno ya existente. El repositorio replicado se indica mediante su URL. La copia de trabajo inicial será la de la rama MASTER

- add, rm, mv

Permite identificar los ficheros del área de trabajo que van a ser incluidos en el repositorio. Para seleccionar ficheros se usa el comando add, para deseleccionarlos el comando a utilizar será rm. El borrado de ficheros no tiene carácter retroactivo sobre las versiones anteriores.

- status

Untracked: no guardados en el repositorio. GIT ignora el fichero.
Unmodified: igual que en la rama activa del repositorio.
Modified: con cambios respecto al repositorio, pero que no está previsto que sean guardados al hacer commit.
Staged: el fichero está en el index. Será parte del próximo changeset que se añadirá al repositorio.

commit

Crea una nueva versión en el repositorio local, incluyendo los cambios en estado Staged procedentes del área de trabajo.

Los ficheros pasan a estar seleccionados como parte de las nuevas versiones con el comando add. El comando git commit -a incluye en el index todos los ficheros del área de trabajo diferentes a los disponibles en el repositorio local, a continuación aplica un commit creando una nueva versión.

push

Sube las versiones del repositorio local a un repositorio remoto. El repositorio remoto puede establecerse con:

- git clone (en este caso se denomina origin).
- git remote add

El repositorio debe tener todas las versiones del repositorio remoto, en otro caso, deberá realizarse un git pull previo.

Aquí tienes una referencia al comando git remote.

- Observar en la figura que el comando push ha dado error, el motivo es que el repositorio remoto tiene recogidos cambios de otros colaboradores que no han sido volcados al repositorio local. Si no se combinan ambos, podría producirse pérdida de información, por lo que sugiere hacer un pull previo al push.
- checkout
  Extrae versiones del repositorio local a la copia de trabajo, la acción se puede realizar sobre diferentes elementos del repositorio:
  - Un fichero: git checkout fichero.
  - Una version: git checkout hash_de_versión.
  - Un branch: git checkout branch.
  También permite crear nuevas ramas, con git checkout -b nombre_rama.

- branch
  
  Lista, crea o elimina ramas en un repositorio.
- Otros comandos de interés son:
  - git log: historia de cambios de un repositorio.
  - git diff: Muestra los cambios de los ficheros en estado modified.
  - git merge: fusión de dos ramas.
  - git gui: interfaz gráfica para utilizar GIT.

e.- Gitk

Gitk es un visor del repositorio local. Permite revisar ramas, commits y merges entre otros.

Es una aplicación útil para:

Recuperar versiones antiguas de un fichero.
Visualizar las ramas de un repositorio.
Hacer un seguimiento de la actividad en el repositorio.

Anexo IV.- Práctica de refactorización en Eclipse

A continuación se propone un ejercicio en el que se ponen en práctica algunas de las funciones disponibles en las opciones de menú Código fuente y Refactorizar en Eclipse.

a.- Enunciado

Los pasos a seguir son los siguientes:

Crear el proyecto:

Crear un proyecto Eclipse llamado “refactor”.
Crear un paquete “utilidades” y dentro crear la clase Circulo.
Crear un paquete “figuras” y dentro crear la clase Test.

Nota: puedes ver el código más adelante. Pulsa aquí si quieres descargarlo.

Utilizando las opciones del menú Código fuente, resuelve los siguientes pasos:

Generar métodos get y set para la clase Circulo.
Corregir la tabulación del código.
Dar formato al código.

Utilizando las opciones del menú Refactorizar, resuelve los siguientes pasos:

Mover la clase Circulo al paquete figuras.
Renombrar la clase Circulo por Circunferencia. Observar si el cambio afecta a otras clases (en este caso Test).
Renombrar el atributo "rad" por "radio". ¿Cómo afecta al método get?.
Convertir la variable local "color" del método imprimir en un atributo, inicializando su valor en el mismo método imprimir.
En imprimir, en lugar de calcular y escribir el diámetro directamente en el println, extraer a una variable local "d" e imprimir dicha variable.
Hacer que 3.1416 sea una constante llamada PI.
Extraer el cálculo del área a un método llamado calcularArea. No recibirá parámetros y devolverá un double.
Cambiar la firma o cabecera del método esIgual, invirtiendo el orden de los parámetros y cambiando el nombre de conDecimales por considerarDecimales. ¿Cómo afecta el cambio a la clase Test, en la que se usaba este método?.
Ahora se propone usar "inline" para deshacer algunos cambios, es decir, hacer el código más concreto. Seleccionar la variable "d" (diámetro) y hacer que su valor se use en línea, desapareciendo por tanto la variable.
Seleccionar la llamada al método calcularArea y hacer que su código se incorpore en la misma línea, desapareciendo la necesidad de usar el método (se puede borrar el método después).
Seleccionar la constante PI y hacer que su valor se incorpore a las líneas en que se usa, desapareciendo por tanto la constante.
Se propone repetir el paso anterior con el atributo "color". ¿Es posible eliminar este atributo y utilizar su valor en línea?.

Código de las dos clases:

Clase Circulo (paquete utilidades)

package utilidades;
public class Circulo {
           private double rad;
           public Circulo(double radio)
           {
                      this.rad = radio;
           }
           public void imprimir()
           {
                        String color = "rojo";
                        System.out.println("Diámetro: " + 2*rad);
                        System.out.println("Color: " + color);
                        double area = 2 * 3.1416 * rad * rad;
                         System.out.println(area);
           }
           public boolean esIgual (Circulo otro, boolean conDecimales)
           {
                          double radio1 = this.rad;
                          double radio2 = otro.getRad();
                          if (conDecimales)
                          {
              if (radio1 == radio2)
                    return true;
              else
                    return false;
          }
          else
                          {
              if (Math.abs(radio1-radio2)<1)
                    return true;
              else
                    return false;
          }
    }
}

Clase Test (paquete figuras)

package figuras;
public class Test {
           public static void main (String[] args)
           {
                    Circulo c1 = new Circulo(5.5);
                    Circulo c2 = new Circulo(10.1);
                    Circulo c3 = new Circulo(10.9);
 
                    if (c2.esIgual(c3, false))
                   {
                            System.out.println("c2 y c3: iguales sin considerar decimales");
                   }
 
                    if (c2.esIgual(c3, true))
                   {
                            System.out.println("c2 y c3: iguales considerando decimales");
                   }
          }
}

b.- Solución de la práctica.

A continuación se muestran algunas indicaciones sobre como resolver la actividad.

	Opción a probar	Solución propuesta
1	Crear un proyecto Eclipse llamado “refactor”.	Menú principal: Archivo/Nuevo/Proyecto/Proyecto Java.
2	Crear un paquete “utilidades” y, dentro, una clase Circulo.	Pulsar el botón derecho del ratón sobre el proyecto refactor: Nuevo/paquete. Pulsar el botón derecho del ratón sobre el paquete utilidades: Nuevo/clase.
3	Crear un paquete “figuras” y, dentro, una clase Test.	Idem anterior. Con el código inicialmente ofrecido, el programa no compila.
4	Mediante las utilidades de "Código fuente": Generar métodos get y set para la clase Circulo. Corregir la tabulación del código. Dar formato al código.	Generar métodos de obtención y establecimiento. Sangrado correcto. Formatear.
5	Mover la clase Circulo al paquete figuras.	Sobre el nombre de la clase, pulsar el botón derecho del ratón: refactorizar/mover. Continuar a pesar de la advertencia.
6	Renombrar la clase Circulo por Circunferencia. Observar si el cambio afecta a otras clases (en este caso Test).	Sobre el nombre, pulsar el botón derecho del ratón: refactorizar/redenominar.
7	Renombrar el atributo "rad" por "radio". ¿Cómo afecta al método get?.	Actualiza el parámetro devuelto, pero no modifica la signatura del método.
8	Convertir la variable local "color" del método imprimir en un atributo, inicializando su valor en el mismo método imprimir.	Sobre la variable local, pulsar el botón derecho del ratón: refactorizar/convertir variable local en campo.
9	En imprimir, en lugar de calcular y escribir el diámetro directamente en el println, extraer a una variable local "d" e imprimir dicha variable.	Sobre la variable area incluida en la instrucción pirntln, pulsar el botón derecho del ratón: refactorizar/extraer variable local.
10	Hacer que 3.1416 sea una constante llamada PI.	Sobre 3.1416, pulsar el botón derecho del ratón: refactorizar/extraer constante.
11	Extraer el cálculo del área a un método llamado calcularArea. No recibirá parámetros y devolverá un double.	Sobre la instrucción que realiza el cálculo , pulsar el botón derecho del ratón: refactorizar/extraer método
12	Cambiar la firma o cabecera del método esIgual, invirtiendo el orden de los parámetros y cambiando el nombre de conDecimales por considerarDecimales. ¿Cómo afecta el cambio a la clase Test, en la que se usaba este método?.	Sobre la cabecera del método, pulsar el botón derecho del ratón: refactorizar/cambiar signatura del método. En los sitios donde es usado ha cambiado el orden de los parámetros automáticamente.
13	Ahora usaremos "inline" para deshacer algunos cambios, es decir, hacer el código más concreto. Seleccionar la variable "d" (diámetro) y hacer que su valor se use en línea, desapareciendo por tanto la variable.	Sobre la variable d, pulsar el botón derecho del ratón: refactorizar/Incorporar.
14	Seleccionar la llamada al método calcularArea y hacer que su código se incorpore en la misma línea, desapareciendo la necesidad de usar el método (puedes borrar el método después).	Sobre la llamada al método, pulsar el botón derecho del ratón: refactorizar/Incorporar.
15	Seleccionar la constante PI y hacer que su valor se incorpore a las líneas en que se usa, desapareciendo por tanto la constante.	Sobre la aparición de PI en la función, pulsar el botón derecho del ratón: refactorizar/Incorporar.
16	Intenta hacer la misma operación con el atributo "color". ¿Es posible eliminar un atributo y utilizar su valor en línea?	No, porque se trata de un valor variable que puede cambiar en otras partes del código, al contrario que los casos anteriores.

Anexo V.- Práctica con GIT

GIT es un software de control de versiones que dispone de infinidad de posibilidades, en este documento vamos a hacer un pequeño repaso de aquellas que nos pueden resultar más útiles en nuestro día a día.

En la web de GIT se dispone de GIT para diversas plataformas:

https://git-scm.com/downloads

En este ejemplo se va a trabajar con la versión de Linux Debian y el IDE Eclipse.

Considérese el siguiente escenario:

Repositorio principal, donde diferentes usuarios ponen la información en común.
Repositorio local-consola, se trata de una zona de trabajo para un usuario que actuará sobre la información desde un terminal. Asociado al repositorio principal.
Repositorio local-eclipse, se trata de una zona de trabajo para un usuario que irá modificando la información desde el IDE Eclipse. Asociado al repositorio principal.

	GitRepo - Repositorio principal.
	GitLocal - Repositorio local-consola.
	GitEclipse - Repositorio local-eclipse.

Para no tener problemas de permisos durante el desarrollo de la práctica, se asignarán permisos completos al árbol de directorios que cuelgan de /home/debian/Escritorio/GitEjer, para ello desde un terminal con permisos de administrador:

cd /home/debian/Escritorio
chmod -R 777 ./GitEjer/

Nota: en un entorno real, en lugar de dar permisos de acceso completos, habría que aplicar sólo aquellos estrictamente necesarios.

Dispondremos de GIT en nuestro equipo Debian mediante su instalación desde repositorio. Para ello, con permisos de administrador, ejecuta desde consola los comandos.

apt-get update.
apt-get install git.

a.- Puesta en marcha.

Crear el repositorio inicial.

Mediante el uso del comando git init se crea el repositorio principal vacío.

Captura de pantalla que muestra cómo se crea el repositorio inicial de la práctica en Git.

Crear proyecto HolaMundo en Eclipse.

Crear en Eclipse un proyecto Java HolaMundo y una clase HolaMundo.java que implemente el método main.

Crear repositorio local-Eclipse.

Pulsar el botón derecho sobre el proyecto => Team/Compartir proyecto/

Hacer el primer commit.

Volcado de la información del área de trabajo al repositorio local-Eclipse. Opción Team/Commit.

Previo al commit, habrá que seleccionar los ficheros del proyecto candidatos a formar parte del repositorio (Unstaged => Staged): seleccionarlos + Botón derecho + Add to Index.

Finalmente, introducir un mensaje y pulsar el botón Commit.

Captura de pantalla que muestra cómo se crea el primer commit de la práctica en Git.

Desde consola podemos ver que el commit se ha realizado de forma satisfactoria.

Enlazar el repositorio local-Eclipse al repositorio Principal.

Haciendo un primer push nos pedirá información del repositorio Principal que todavía no tiene asociado. /Team/push branch 'master'.

Captura de pantalla que muestra cómo se enlaza el repositorio local-Eclipse al repositorio principal de la práctica en Git.

Una vez introducida la información en la ventana, habrá que ir comprobando cierta información que nos va mostrando Eclipse (botón Preview) y finalmente pulsar el botón Push.

Captura de pantalla que muestra cómo se comprueba que la información se va mostrando en Eclipse de la práctica en Git.

Descargar el repositorio Principal al repositorio local-consola.

Volcado del repositorio principal al área de trabajo local de consola con git clone.

b.- Trabajando en el repositorio local - consola.

En este apartado se va a modificar información en el repositorio local-consola, para posteriormente hacer un volcado de la información al repositorio principal.

Los pasos a realizar son:

Modificar información en el área de trabajo local. Se realiza con el editor linux nano para modificar el fichero HolaMundo.java ubicado en la ruta /home/debian/Escritorio/GitEjer/GitLocal/GitRepo/HolaMundo/src.
Seleccionar los ficheros modificados como candidatos para ser volcados al repositorio local. Comando add.
Identificar el usuario que opera en esta copia local mediante el comando git config --global.
Volcado de la información desde el área de trabajo al repositorio local. Comando commit.

Para poder subir los cambios al repositorio principal desde consola, éste no debe tener como rama activa la destinataria (master en este caso).

La siguiente imagen muestra que la única rama existente en el repositorio principal al principio es la master. Se creará una segunda rama ( Rama 1) y se marcará como activa (checkout).

Ahora ya es posible enviar los cambios del repositorio local-consola al repositorio principal mediante el comando push.

c.- Trabajando en el repositorio local - Eclipse.

En este apartado se va a modificar información en el repositorio local-eclipse. Posteriormente se hace un volcado de la información al repositorio principal.

En primer lugar habrá que ponerse al día con el repositorio Principal. /Team/Pull, puesto que éste ha sido modificado en el apartado anterior desde el repositorio local de consola.

Equivale a:

Fetch. Descarga de la versión del repositorio principal al repositorio local.
Merge. Mezcla del repositorio local con el área de trabajo. Si no hay conflictos, se realiza automáticamente. En caso de haberlos, será el programador quién habrá de tomar la decisión de resolverlos. Ver siguientes apartados.

Modificar el código en el área de trabajo Eclipse sin hacer commit al repositorio local. Observa que Eclipse nos advierte de esta situación marcando el proyecto con el símbolo ">". El área de trabajo no está sincronizada con el repositorio local. No obstante, si hacemos un Pull, nos advierte que todo está al día; en este caso compara los repositorios Principal y Local-Eclipse.

Sincronizar el repositorio local-eclipse con el principal. Team/push branch master.

Sincronizar el repositorio local -consola desde el repositorio principal.

Finalmente, actualizamos el repositorio local-consola para que considere los últimos cambios volcados en el repositorio principal.

Observa que git status no advierte de discrepancias de código puesto que el área de trabajo local está sincronizada con el repositorio local - consola. Se puede ver que los cambios no están presentes en el fichero HolaMundo.java visualizado con el comando more.
El comando git pull actualiza el repositorio-local y el área de trabajo desde el repositorio principal.

d.- Gestión de conflictos - 1

Modificar ambos repositorios locales a partir de una versión común y combinar todos los cambios para tener una versión final en el repositorio Principal con modificaciones conjuntas.

Subir en primer lugar en Eclipse y consolidar desde consola.

La siguiente figura muestra cambios introducidos en eclipse y su commit al repositorio local-eclipse.

A continuación se muestran los cambios del proyecto en la versión local de consola y su commit.

Captura de pantalla que muestra los distintos pasos que hay que realizar para subir en primer lugar en Eclipse y consolidar desde consola en la práctica en Git.

Subir los cambios del repositorio-eclipse al repositorio principal (Team/push branch master.). Antes de lanzar el push siempre es mejor hacer un pull para ver si trabajamos sobre la última versión del repositorio principal.

En este caso, no hay conflictos porque los últimos cambios/commit se han hecho sobre la última versión que se subió al repositorio principal. Team/Push to branch master.

Ahora toca subir los cambios realizados en el repositorio local-consola al principal. Previo al push (subida de cambios) hacemos un pull para combinar las modificaciones que anteriormente hemos subido desde Eclipse.

El comando pull hace un fetch con lo que el repositorio local-consola y principal quedan en la misma versión y un merge que combina el repositorio local-consola con el área de trabajo. Ahora el nuevo fichero combinado considera los cambios locales y los procedentes del pull. Como no es posible resolver automáticamente las discrepancias, el programador será quien tenga que decidir sobre cómo quedará el código final combinado.

Finalmente habrá que hacer un commit y un push del fichero que ya combinará las actualizaciones realizadas desde ambos ámbitos locales de trabajo.

Solo faltaría hacer un pull en Eclipse para que quede también actualizado.

e.- Gestión de conflictos - 2.

Modificar ambos repositorios locales a partir de una versión común y combinar los cambios de ambos para tener una versión final en el repositorio Principal con modificaciones conjuntas.

Subir en primer lugar en consola y consolidar desde Eclipse.

En primer lugar se modificarán las zonas de trabajo locales y se actualizan sendos repositorios locales.

Subir los cambios del repositorio-consola al repositorio principal (push). Antes de lanzar el push siempre es mejor hacer un pull para ver si trabajamos sobre la última versión del repositorio principal.

Antes de hacer un push en Eclipse, habrá que comprobar si el repositorio principal está en la misma versión que el local (no que el área de trabajo), y si no lo está, solicitar un pull (fetch + merge) para poner en común los cambios en ambos repositorios. Team/Pull.

GIT no ha sido capaz de decidir como sincronizar los cambios y nos muestra una combinación de ambos (véase la figura anterior) para que sea el programador quien tome la decisión sobre como hacerlo. Una vez cambiados, se hará un commit al repositorio local-Eclipse y un push a continuación para subir la versión que recoge todas las modificaciones al repositorio principal.

Si ahora se solicita un pull desde Eclipse, avisa de que no hay información que actualizar. Los dos repositorios Principal y local-Eclipse están sincronizados.

El que ha quedado desincronizado es el repositorio local-consola respecto al repositorio principal.

Como no ha habido cambios en local - ningún commit desde la última vez que estuvo sincronizado (último pull). Un nuevo pull deberá actualizar el repo local sin necesidad de hacer sincronización de cambios manuales.

f.- Comandos Git, Status, Log.

git status . Estado de los archivos en el directorio de trabajo y en el staging area.

git log. Mostrar la historia de commits en un branch.

git show. Información sobre el último commit, y los cambios que produjo.

Anexo VI.- Práctica con GitHub

GibHub es un gestor de versiones GIT disponible en la nube. Está accesible en la url: https://github.com/.

a.- Alta de cuenta en GitHub.

Para crear una nueva cuenta, habrá que pulsar en el enlace "Sign in", que muestra la ventana de acceso para usuarios GIT, y que además ofrece la opción de crear una nueva cuenta mediante el enlace "Create an account".

A partir de este punto, un asistente irá guiando la creación de la cuenta.

b.- Crear un repositorio.

Para ilustrar las actividades que se van a llevar a cabo en este documento, se va a dar de alta el repositorio HolaMundoGit. A continuación, se volcará la información del repositorio Eclipse local con el que se ha trabajado en el anexo V.

Una vez creado, el repositorio está disponible en una url del tipo:

https://github.com/usuario/repositorio

Para este ejemplo será:

https://github.com/josemanuelmoreno1/HolaMundoGit

El repositorio está inicialmente vacío.

c.- Carga de información en el repositorio HolaMundoGit de GitHub.

En este apartado se sincronizará el repositorio recién creado con los repositorios utilizados en el anexo V (en particular con Eclipse local).

Pulsar el botón derecho del ratón sobre el proyecto y seleccionar la opción de menú Push: /Team/Push branch master

En la figura superior, se puede comprobar que el repositorio remoto seleccionado es el disponible en GitHub.

Pedirá el usuario/contraseña que tenemos en la cuenta de GitHub.

Para finalizar, confirmar el Push.

Se puede observar que el proyecto HolaMundoGit ya está disponible en el repositorio Github.

d.- Descarga del repositorio HolaMundoGit de GitHub a un repositorio local de consola.

Para crear desde consola un nuevo repositorio local con la información disponible en el repositorio de GitHub, desde un terminal de consola con permisos de administrador:

Crear un nuevo repositorio vacío: git init.
Seleccionar el repositorio remoto con el que estará sincronizado: git remote add.
Descargar el proyecto: git pull.

Se puede observar que tras la descarga, el proyecto ya está disponible en el nuevo repositorio local.

Anexo VII.- Práctica: JavaDoc con Eclipse.

En el punto 3 (Documentación) se describen algunas de las funcionalidades proporcionadas por la herramienta JavaDoc. Para poner en práctica su uso utilizaremos el IDE Eclipse y el proyecto Semaforo ya utilizado en otras prácticas durante el curso. Para descargar dicho proyecto, pulsa aquí.

Partiendo del código del proyecto Semaforo, se van a incluir una serie de comentarios y etiquetas JavaDoc distribuidos por el proyecto. El código, una vez modificado, está disponible en este enlace: Proyecto semáforo con comentarios.

En la siguiente figura se puede ver el fichero ordenador.java una vez incluidos los comentarios JavaDoc.

Los pasos a seguir son:

Sobre el código fuente del proyecto, incluir los comentarios JavaDoc que se consideren oportunos.
Seleccionando el proyecto semaforo, acceder a la función "Generar Javadoc" en la opción de menú Proyecto de la barra de herramientas.

En la ventana "Generar Javadoc" que aparece, seleccionar como "Mandato javadoc" el ejecutable Javadoc que viene integrado en el paquete jdk e indicar la ruta donde queremos que se guarde la documentación generada.

Una vez generada la documentación, estará disponible en la ruta seleccionada como destino en la ventana anterior. El resultado es una estructura web cuyo fichero de inicio es index.html. Si pulsas aquí te puedes descargar el javaDoc generado.

En la siguiente figura se muestra el aspecto que tiene la documentación generada. En particular, se presenta la clase ordenador del proyecto.

Anexo VIII.- Licencias de recursos.

Recurso (1)	Datos del recurso (1)	Recurso (2)	Datos del recurso (2)
	Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.		Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.
	Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.		Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.
	Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.		Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.
	Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.		Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.
	Autoría: Gnome.org. Licencia: GNU. Procedencia: Captura de pantalla de gnome.org.		Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.
	Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.		Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.
	Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.		Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.
	Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.		Autoría: Ministerio de Educación. Licencia: Uso Educativo no comercial. Procedencia: Elaboración propia.
	Autoría: Ministerio de Educación. Licencia: Uso Educativo no comercial. Procedencia: Elaboración propia.		Autoría: Ministerio de Educación. Licencia: Uso Educativo no comercial. Procedencia: Elaboración propia.
	Autoría: Ministerio de Educación. Licencia: Uso Educativo no comercial. Procedencia: Elaboración propia.		Autoría: Ministerio de Educación. Licencia: Uso Educativo no comercial. Procedencia: Elaboración propia.
	Autoría: Ministerio de Educación. Licencia: Uso Educativo no comercial. Procedencia: Elaboración propia.		Autoría: Ministerio de Educación. Licencia: Uso Educativo no comercial. Procedencia: Elaboración propia.
	Autoría: Ministerio de Educación. Licencia: Uso Educativo no comercial. Procedencia: Elaboración propia.		Autoría: Ministerio de Educación. Licencia: Uso Educativo no comercial. Procedencia: Elaboración propia.
	Autoría: Ministerio de Educación. Licencia: Uso Educativo no comercial. Procedencia: Elaboración propia.		Autoría: Ministerio de Educación. Licencia: Uso Educativo no comercial. Procedencia: Elaboración propia.
	Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.		Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.
	Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.		Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.
	Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.		Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.
	Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.		Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.
	Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.		Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.
	Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.		Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.
	Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.		Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.
	Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.		Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.
	Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.		Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.
	Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.		Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com		Autoría: GIT. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GitHub. Licencia: Copyright cita. Procedencia: github.com		Autoría: GitHub. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GitHub. Licencia: Copyright cita. Procedencia: github.com		Autoría: GitHub. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GitHub. Licencia: Copyright cita. Procedencia: github.com		Autoría: GitHub. Licencia: Copyright cita. Procedencia: github.com
	Autoría: GitHub. Licencia: Copyright cita. Procedencia: github.com		Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.
	Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.		Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.
	Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.		Autoría: Oracle Corporation. Licencia: Copyright cita. Procedencia: Captura de pantalla de Netbeans.
	Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.		Autoría: eclipse.org Licencia: Copyright cita. Procedencia: Captura de pantalla de Eclipse.

Retroalimentación

Pregunta

Respuestas

Retroalimentación

Solución

Pregunta

Respuestas

Retroalimentación

Solución

Pregunta

Respuestas

Retroalimentación

Solución

Pregunta

Respuestas

Retroalimentación

Solución

Pregunta

Respuestas

Retroalimentación

Solución

Pregunta

Respuestas

Retroalimentación

Solución

Pregunta

Respuestas

Retroalimentación

Solución