Tema 3. Control de versiones^J optimizacion y documentación.pdf

Control de versiones, optimización y documentación Tema 3 Control de versiones, optimización y documentación 0 Control de versiones, optimización y documentación 1. Control de versiones 1.1. Introducción El objetivo de los sistemas de control de versiones es mantener actualizada la estructura...

Control de versiones, optimización y documentación Tema 3 Control de versiones, optimización y documentación 0 Control de versiones, optimización y documentación 1. Control de versiones 1.1. Introducción El objetivo de los sistemas de control de versiones es mantener actualizada la estructura de directorios y archivos de los proyectos, así como el contenido de los mismos, así como crear un registro compartido de los cambios realizados por los programadores del equipo, indicando quien ha hecho los mismos, y las diferentes versiones que se han generado durante la fase de desarrollo. Logo de Git 1.2. Estructura, funcionamiento y tipos de herramientas de control de versiones Las herramientas de control de versiones funcionan a partir de un servidor donde se almacenan los archivos a implementar en un repositorio. Dichos archivos se descargan a un equipo cliente donde se modifican y posteriormente se vuelven a subir al repositorio par ser compartidos por todos los miembros del equipo de trabajo. Cada proyecto se estructura como un árbol -trunk- donde se encuentra la versión principal del proyecto, con ramas que corresponden a nuevas funcionalidades o depuración de errores o nuevas versiones del producto. Asimismo se incluyen etiquetas que indican versiones finalizadas, copias del trunk.. Logo de Subversion Conceptos versiones asociados al control de Repositorio: almacenamiento de la informacion del proyecto que se va actualizando Versión: revision almacenada. de la informacion HEAD: es la version más reciente de los datos almacenados Tag: etiqueta que permite identificar una version concreta. Trunk: es la línea principal de desarrollo de un proyecto Si varios miembros del equipo trabajan a la vez sobre el mismo archivo y cabe la posibilidad de un conflicto, se generará un archivo intermedio que incluye todos los cambios para ser revisados, en caso contrario se fusionan todos los cambios en un archivo definitivo. Existen varios tipos de herramientas de control de versiones: • Herramientas locales: permiten crear el repositorio en un equipo local donde se almacenan todas las versiones de los documentos creados, para recuperarlos con facilidad • Herramientas centralizadas: el repositorio está almacenado en un servidor, al que se conectan los miembros del equipo para almacenar los archivos, recuperarlos y modificarlos. Entre estas herramientas esta Apache Subversion (SVN) • Herramientas distribuidas: cada usuario tiene varios repositorios replicados en diferentes servidores, para minimizar la perdida de información en caso de fallo. Como consecuencia de lo anterior existen dos formas de tra- 58 Control de versiones, optimización y documentación bajar con un sistema de control de versiones: • • Cada desarrollador se ocupa de una parte del software de manera que mientras lo desarrolla, el repositorio lo bloquea para evitar modificaciones. Una vez lo desarrolla, lo sube al repositorio que desbloquea para subir la nueva versión Varios desarrolladores trabajan en diferentes versiones del código que suben al repositorio, lo cual obliga a gestionar las diferentes versiones del mismo. Lo anterior obliga a implementar un flujo de trabajo para evitar las duplicidades y los problemas de versiones. Dicho flujo de trabajo puede gestionarse de varias maneras: • • • De manera centralizada, donde los desarrolladores suben el código al repositorio, que bloquea dicha parte del mismo para que solo ese desarrollador pueda subir versiones del mismo Con un gestor de integración, que actualiza el repositorio común con los archivos subidos a los repositorios públicos por los desarrolladores Con varios gestores de integración de partes del proyecto -tenientes- y un supergestor -dictador- que actualiza la información del repositorio común con los datos que le ofrecen los gestores de integración. Para trabajar en proyectos utilizando un sistema de control de versiones se debe crear una copia del repositorio común en local con checkout, y posteriormente subir sus cambios al repositorio con commit, actualizando previamente con update para que su versión local sea la misma que la del repositorio común. Existen diferentes sistemas de control de versiones en el mercado, como hemos visto en el apartado anterior. Los más interesantes son SVN o Subversion, y Git / GitHub. 2. Herramientas de control de versiones 2.1. Git 2.1.1. Introducción: concepto y características Git es una herramienta de control de versiones distribuida desarrollada por Linux Torvalds, en la que los usuarios pueden trabajar en equipo controlando, mezclando y fusionando las modificaciones en el código implementado, pudiendo etiquetar las versiones de documentos, y ver el historial de los 59 Branch: es una copia del proyecto para corregir errores o añadir funcionalidades Desplegar: crea una copia de trabajo del proyecto con la ultima version por defecto, que se enlaza con la carpeta local del proyecto Commit: confirmacion de los cambios producidos en la version Pull: copia los cambios del repositorio en la carpeta local. Push / fetch: añade los cambios en el repositorio local al repositorio común Cambio: modificacion de un documento que está en control de versiones. Sincronización: combinar las cambios hechos al repositorio con la copia de trabajo local. Exportación: similar a checkout Importación: subir los archivos locales al repositorio Actualización: integración de los cambios realizados en el repositorio en la copia de trabajo local. Fusión: une los cambios generados en varias versiones en una única versión. Revert: vuelve a una versión anterior Conflicto: se produce cuando un usuario no actualiza sus datos en el repositorio local a la última version e intenta añadir sus propios cambios y subirlos al repositorio común. Control de versiones, optimización y documentación mismos. instruccion Descripcion init Convierte en repositorio local una carpeta local status Muestra los cambios realizados en el directorio de trabajo add Añade ficheros al área de preparación commit Valida los cambios producidos en los archivos. Con el parámetro -m permite añadir un mensaje a la operación de validación log Permite ver el historial de revisiones del repositorio. Con –pretty format =” %h %an %ar -%s” show Muestra las versiones aprobadas commited- . Con el parametro -iDcommit se muestra diff Compara la version mas reciente aprobada con la version almacenada en el directorio de trabajo. Con los parametros HEAD-I HEAD muestra las diferencias entre la version de i momentos anteriores y la actual. Con el parámetro -stagged se compara lo que hay en el directorio de trabajo con el area de preparacion. Reemplaza el contenido del directorio de trabajo con la última version validada. Se puede poner como parámetro el nombre del archivo concreto o el de la rama a restaurar Herramienta visual para ver los cambios en los archivos del repositorio. Con el parametro <nombr_fichero> muestra los cambios en un fichero concreto. checkout diftool reset restore revert branch blame tag Permite pasar el fichero que se pasa por parámetro de la zona de preparacion a la de trabajo. Con el parámetro –hard elimina los ficheros del área de preparación y del directorio de trabajo dejando lo que había antes de la última confirmacion o commit Devuelve el fichero que se pasa por parámetro al estado anterior a los cambios. Seguido de HEAD deshace los cambios del último commit ,seguido de –abort, aborta la orden anterior de reversion, seguido de –skip se salta el paso Permite ver la rama local en la que está el usuario. Con los párametros -v -a permite ver la rama local y remota. Con los parámetros <nombre_rama> y <rama_origen> crea una nueva rama a partir de la rama origen. Permite ver toda la informacion de un fichero -creador, historial de cambios- Con el parametro -a <nombre_etiqueta> -v <mensaje> asigna una etiqueta a una version Instrucciones de Git de trabajo en local Un archivo que se carga en Git pasa por cuatro áreas, que son: • El directorio de trabajo: donde se realizan las localizado en operaciones de creación y modificación de los documentos. Los archivos en esta zona están en estado untracked o modificados. Emplea las siguientes instrucciones para gestionar los datos y enviarlos al área de preparación git add / mv / rm / commit -a / diff • El área de preparación: donde se prepara a los archivos para validarlos en el repositorio local. Los archivos en esta zona están en estado stagged o preparados. Se emplean los comandos siguientes para pasar los datos al repositorio local git commit Por otro lado, emplea los siguientes comandos para comunicarse con el directorio de trabajo git reset(file) /diff • El repositorio local: es donde se guardan las diferentes versiones de los archivos. Los archivos en esta zona están en estado commit o confirmado Emplea los comandos siguientes para comunicarse con el repositorio remoto git push y las siguientes instrucciones para comunicarse con el directorio de trabajo y viceversa git diff HEAD • el repositorio remoto: es donde se permite sincronizar las modificaciones realizadas por los diferentes miembros del grupo de trabajo, y al que podemos acceder desde cualquier equipo. Emplea la siguiente instrucción para comunicarse con el repositorio local git fetch 60 Control de versiones, optimización y documentación 2.1.2. Operaciones con Git Las operaciones con git se realizan empleando los comandos que se muestran en el cuadro de la derecha, y permiten realizar las tareas de creación de repositorios, añadir y quitar archivos de las diferentes áreas, pasarlos de unas a otras y ver las diferencias entre las distintas versiones de los archivos, revertir los cambios producidos en estas y otras tareas de gestión. Para poder realizar dichas operaciones se emplea una consola llamada Git bash, que emplea las instrucciones propias de Linux-UNIX para las tareas de gestión de directorios y archivos, o también un interfaz gráfico, Git GUI. Así mismo, también se puede trabajar desde Eclipse en Git, activando la perspectiva git, lo cual nos permite realizar las mismas operaciones que en modo consola pero empleando el IDE. En el apartado de prácticas realizaremos ejercicios de ejemplo que nos permitirán manejar dichos comandos correctamente. 2.2. GitHub 2.2.1. Introducción: concepto y características GitHub es un repositorio en la nube que permite compartir los cambios que realizan los diferentes miembros del equipo de trabajo enviándolos desde los repositorios locales, y descargándolos de ellos. 2.2.2. Operaciones con GitHub Las operaciones en GitHub emplean los comandos de Git específicos de acceso remoto, así como los comandos ya vistos de acceso local. Dichos comandos se pueden ver en el cuadro de la izquierda de esta página. Entre las tareas que se llevan a cabo con dichos comandos están la conexión con el repositorio remoto -de nombre origin/master, cuyo repositorio local se llama master-, el clonado de repositorios, la creación de usuarios en el repositorio local, la recuperación de archivos del repositorio remoto, la fusión de ramas y otros. 2.3. Subversion 2.3.1.Concepto y características Subversion -SVN- es una herramienta de control de versiones 61 instruccion Descripcion clone Clona el repositorio remoto. El parametro es la direccion URL. Va seguida de un punto Con el parámetro –global crea un usuario en el repositorio remotor config remote add Se conecta con el repositorio pasado por parámetro push Sube los archivos confirmados al repositorio remoto. Tiene como parámetros el nombre del repositorio remoto y el de la rama del mismo Permite traer el repositorio remoto con los parametros el nombre del repositorio dremoto y el de la rama del mismo. Con los parametros <rama_origen> <rama_destino> fusiona dos ramas en una. fetch merge Instrucciones de Git de trabajo en remoto Control de versiones, optimización y documentación que permite trabajar de manera transparente creando, borrando y modificando archivos como si estuviera trabajando en el disco duro. Subversion permite trabajar en red, de modo que diferentes usuarios pueden trabajar con el mismo proyecto de modo que todos los desarrolladores del proyecto pueden tener la versión más actualizada de los archivos del proyecto. 2.3.2.Operaciones con Subversion SVN tiene implementadas, entre otras, las operaciones siguientes: • Checkout: que descarga en el equipo una copia del contenido del repositorio • Update: descarga en el equipo las modificaciones que hayan tenido lugar desde la última sincronización • Commit: actualiza el contenido del repositorio remoto con los cambios producidos solo si no hay conflictos con el código ya existente 2.4. Subversive 2.4.1. Concepto y características El proyecto Subversive, se creó específicamente para trabajar con Subversion y permite integrar la herramienta de control de versiones SVN bajo Eclipse, de manera análoga a como se utilizan en los antiguos sistemas de control de versiones -CVS-. Subversive permite navegar por el repositorio remoto, compartiendo los proyectos en él, y sincronizar el proyecto para ver las modificaciones producidas, así como realizar y revertir las actualizaciones. Entre las ventajas que tiene está el trabajar con ficheros binarios, que las modificaciones son atómicas y el trabajar en torno a Apache. Entre las carencias está que las operaciones de renombrado de ficheros tienen que realizarse como una actividad de copia seguida de una de borrado, en vez de poder realizar una actividad de cambio de nombre de manera atómica. 2.4.2. Operaciones con Subversive Entre las operaciones que se pueden realizar con Subversive están las operaciones de sincronización, commit, actualización, reversión, así como mostrar el historial de cam- 62 Control de versiones, optimización y documentación bios producidos en las versiones. 3. Optimización y refactorización de código • Codigo duplicado que se puede extraer para crear un método que se llame desde diferentes partes del programa • Clases demasiado grandes, por la misma razón que en el punto anterior • Demasiados parámetros, que indica que podrían agruparse en un único objeto, sobre todo si están relacionados entre sí y se repiten en muchos métodos • Cambios demasiado frecuentes codificación de una clase • Cambios en demasiadas clases al modificar una determinada • Problemas de acoplamiento al emplear métodos de una clase más parámetros de otra que de la suya propia • Clases con solo getters y setters, sin más funcionalidad • Subclases que apenas usan métodos o atributos de su clase padre, lo que implica que no hay una herencia real. • Métodos demasiado largos y complejos que se deben modularizar por la propia naturaleza de la metodología de la programación estructurada y de objetos -cohesión, acoplamiento y reutilización- 3.1. Concepto y características Se entiende por refactorización una serie de técnicas de optimización del código que preserve su comportamiento externo, su funcionalidad. Se realizan en la fase de mantenimiento preventivo, o durante la propia implementación de actualizaciones o nuevas funcionalidades, con el objeto de simplificar el código, modularizarlo y hacerlo más comprensible de cara a futuras necesidades de modificación o actualización. Entre las ventajas de la refactorización están el poder leer el código más rápidamente y corregir errores con mayor facilidad, así como que los códigos serán más robustos. 3.2. Técnicas de refactorización 3.2.1. Indentación La indentación es una de las técnicas de reorganización del código más sencillas y mas efectivas para la mejor comprensión del mismo. No implica modificación del código ni refactorización en el sentido de optimización del mismo, sino que no es más que una reorganización de las líneas de código empleando los tabuladores para visualizar los diferentes niveles de código esto es, las instrucciones dentro de un método estarán situadas a la derecha del método, las instrucciones dentro de una estructura de control estarán a la derecha de la mismade modo que es muy sencillo visualizar donde empieza y termina cada bloque de código. 3.2.2. Renombrado Renombrar una variable, método, clase o paquete es especialmente útil para evitar que se confunda con otros elementos del código, o dar un nombre que indique algo sobre el uso de la variable o el contenido del método, clase o paquete. 3.2.3. Extraer métodos Consiste en tomar fragmentos de código de un método y crear otro método más pequeño, y más específico. Es muy útil para reducir la complejidad de los métodos grandes favoreciendo la cohesión y minimizando el acoplamiento, así 63 en la Características del código susceptibles de refactorización Fragmento de código en el que podemos ver la indentación o sangrado de los diferentes bloques de instrucciones Control de versiones, optimización y documentación cómo crear métodos más grandes a partir de múltiples métodos sencillos 3.2.4. Generar métodos inline Consiste en la tarea inversa a la anterior, evitar factorizar demasiado un método, integrando el código de métodos más pequeños para dejar más claro el funcionamiento de la aplicación, así como evitar el uso de variables temporales para almacenar los datos que devuelve un método indicando directamente el valor a devolver en el return. 3.2.5. Usar variables temporales para almacenar parámetros de un método Permite manejar los datos a través de variables internas del método en vez de directamente en los parámetros, que si son por dirección y no por valor, pueden generar modificaciones en los mismos no deseadas. 3.2.6. Mover métodos de una clase a otra Es necesario cuando los métodos usan más características de otra u otras clases que de la clase en la que se han implementado. También se debe hacer, si cabe, cuando se tienen varias clases relacionadas entre sí, una con muchos métodos y otras con pocos métodos 3.2.7. No reutilizar variables temporales En los métodos conviene utilizar variables temporales diferentes, para lo cual se usa el modificador final, para evitar que una variable se instancie varias veces. 3.2.8. Extraer métodos del cuerpo de instrucciones de una estructura de control Es especialmente útil cuando tenemos una estructura condicional o repetitiva que contiene una serie de instrucciones que se repiten en otras partes del código, de modo que se pueden reutilizar a lo largo del mismo de manera más flexible. 3.2.9. Reemplazar condicionales / conmutaciones con polimorfismo Permite que dado un condicional o un switch que da una respuesta distinta según que el objeto que se analice sea de una clase u otra sea sustituida por el polimorfismo dentro de las clases. 64 Control de versiones, optimización y documentación 3.2.10. Sustituir el uso de una variable por un getter/setter Es imprescindible para garantizar la encapsulación del código y no usar directamente una variable que debe ser private -especialmente los atributos de las clases3.2.11. Sustituir una variable o atributo por un objeto En este caso se trata de que una variable o un atributo en una clase que tenga sus propios atributos y métodos, entre ellos el atributo convertido y sus getters y setters. 3.2.12. Sustituir un objeto por un atributo El caso inverso al anterior, cuando un objeto no se prevé que tenga un desarrollo futuro y solo tenga un atributo, es preferible sustituirlo en las clases que lo utilicen por un atributo. Patrones de refactorización asociados a una variable –la variable session en este caso- 3.2.13. Extraer clases /subclases Cuando una clase incluye dos grupos o más de atributos que tienen relación estrecha interna entre ellos y poca con los otros grupos, o cuando se utilizan algunos atributos siempre enunas determinadas ocasiones y en otras no, conviene dividir la clase en varias o extraer los atributos que solo se usan en determinadas ocasiones para generar una subclase. 3.3. Patrones de refactorización en Eclipse La refactorización en Eclipse emplea las herramientas agrupadas en la opción Refactor del menú principal de Eclipse, que también se encuentran en el menú contextual de los proyectos. Esas herramientas evitan la tarea de una refactorización manual, que puede ser susceptible de producir errores e inconsistencias que alargarán la implementación del código. Patrones de refactorizacion asociados a un método -el método update()- Ejemplo de renombrado de una variables – en este caso la variable elemento- Dichas herramientas se conocen como patrones de refactorización. Podemos ver a continuación una lista de ellos: • Renombrar (rename): cambia el nombre de los elementos seleccionados en Java -métodos, variables, clases, u otros• Mover (move): mueve una clase entre paquetes -si bien también se puede hacer arrastrándola con el ratón de un paquete a otro-. • Extraer constante (Extract constant): permite que un numero o cadena alfanumérica se convierta en una constante. El cambio se extenderá a lo largo de todo el proyecto, de modo que todas las ocurrencias de ese nú- 65 Ejemplo de extraccion de una constante en este caso la frase “la suma es:” Control de versiones, optimización y documentación mero o cadena alfanumérica se sustituyan por una constante. • Extraer variable local (Extract local variable): es semejante a la opción anterior, pero en este caso se crea una variable en vez de una constante • Convert local variable to field (Convertir una variable local en un atributo) Conversion de una variable local en un atributo. • Extract Method(Extraer método): Consiste en tomar parte del código de un método que se repite muchas veces para crear un método propio, de cara a facilitar la encapsulación y la modularidad de la aplicación. • Extract Method(Extraer método): Consiste en tomar parte del código de un método que se repite muchas veces para crear un método propio, de cara a facilitar la encapsulación y la modularidad de la aplicación. • Change method signature (Cambia la cabecera de un método): generará de forma automática todas las llamadas al método y las modificará. • Inline: permite simplificar las líneas de código agrupando varias para simplificar el acceso a un metódo o función. Extraccion de un método. Nótese que el fragmento va entre llaves • Member type to Top Level: convierte una clase hija en una clase padre • Extract Interface( extraer interfaz): selecciona los métodos de una clase para generar una clase Interface • Extract Superclass(Extraer superclase): permite extraer una clase padre a partir de otra. Se selecciona la clase en el proyecto y en Refactor se va a Extract SuperClass, donde se escogen los métodos que formarán la clase padre. Generación de un método inline 4. Documentación 4.1. Concepto y características Generación de una clase padre La documentación de una aplicación software es un elemento fundamental para facilitar el mantenimiento y actualización de la misma por parte de los desarrolladores manual técnico, que debe ser muy detallado para que el desarrollador pueda implementar la aplicación-, y para la instalación de la misma por parte de los administradores manual de instalación- y el manejo de la misma por parte de los usuarios -manual de usuario, que debe de ser sencillo y autoexplicativo para que el usuario pueda saber qué hacer y que no -. 66 Control de versiones, optimización y documentación La documentación de un proyecto se genera tanto antes como durante y después de la fase de desarrollo del software. 4.2. Características de una documentación de calidad Una documentación de calidad se puede generar siguiendo los siguientes consejos • Desarrollar esquemas para organizar la documentación e incluirlos en ella • Clasificar la información de manera que los diferentes documentos que componen la documentación sean manejables Conversion de una variable local en un atributo. • Desarrollar una síntesis de la documentación para dar una visión global de la misma • Emplear las herramientas software propias de los lenguajes de programación para las labores de documentación • Ponerse en el lugar del usuario de la documentación a la hora de prever sus necesidades • Emplear una sintaxis y gramática correctas • Empleo de herramientas colaborativas o de hipertexto para la documentación 4.3. Tipos de documentación 4.3.1. Documentación previa al desarrollo de la aplicación Antes de iniciar un proyecto es preciso determinar o estimar los costes del proyecto y las posibles soluciones, así como cuestiones de tipo administrativo o legal. Todo ello se realiza en los niveles de decisión de la organización que requiere la aplicación o proyecto software 4.3.2. Documentación de la fase de análisis Etiqueta Descripcion @author autor de la clase en el código fuente @version Versión del código fuente @return Descripcion de los datos que devuelve un método @see Redirige a otra parte del código -una clase por ejemplo@since Fecha de creación del programa Extraccion de un método. Nótese el @param Parámetros del que método que se documenta fragmento va entre llaves @deprecated Indica que el método o clase está obsoleto @link<URL> Se dirige al usuario a una direccion URL determinada. @throws Descripcion de una excepción Etiquetas de la documentación de Javadoc Generación de un método inline Durante la fase de análisis se estudia el objetivo de la aplicación, la necesidad que cubre y sus especificaciones. Esta última requiere la norma IEEE 830 e incluye las funcionalidades que debe de tener una aplicación software, que deben tener los apartados de: • Introducción, donde se define el objetivo de la aplicación • Descripción del problema a resolver y los elementos software / hardware necesarios • Descripción de cada una de las funciones que realizará la aplicación. • Descripción del comportamiento del software ante even- 67 Generación de una clase padre Control de versiones, optimización y documentación tos internos y externos • Documentación sobre el rendimiento esperado de la aplicación y las pruebas a realizar La realización de estos documentos requiere una serie de entrevistas con los clientes y usuarios de la aplicación en donde se extraen las funcionalidades y requisitos de la aplicación o el sistema a implementar 4.3.3. Documentación del diseño En la fase de diseño se especifica la estructura de los datos / base de datos, los modelos Entidad-Relación y relacional, los diagramas de escenarios, casos de uso, clases, colaboración, secuencia, etc… así como los métodos y atributos necesarios en cada clase y en el caso de los métodos, los valores de entrada y salida de los mismos 4.3.4. Documentación del código fuente (implementación) En la fase de implementación es necesario documentar el código fuente de cara a facilitar al desarrollador poder comprender el código cuando pasa un tiempo después de haberlo implementado, o bien a desarrolladores que no conocen el código poder trabajar con él. La documentación del código debe de ser detallada e incluir, para cada archivo de código, quien lo creo, el objetivo de la clase o módulo, la versión y el tipo de licencia. Para cada uno de los métodos hay que indicar el tipo de datos que devuelve, los parámetros de entrada, su función y la librería donde aparece -si corresponde-. El comentario del código puede ser de tres tipos: • De línea • De bloque -varias líneas de comentario• De documentación, que se genera de forma automática y contiene información sobre los métodos, las clases y sus funciones, sus valores de entrada y salida 4.3.5. Documentación de la fase de pruebas La documentación de la fase de pruebas especifica con detalle las pruebas a realizar y sus resultados. Tenemos dos tipos de pruebas, las funcionales – en las que se ejecutan las diferentes funcionalidades de la aplicación para comprobar si cumplen las especificaciones y se anotan los errores y las modificaciones realizadas- y técnicas -de instalación, etc…- 68 Control de versiones, optimización y documentación 4.3.6. Documentación de la fase de explotación En esta fase se anotan todas las incidencias de la aplicación, de modo que se puedan corregir los fallos por parte de los programadores 4.3.7. Documentación de la fase de mantenimiento En esta fase se documentan todas las actualizaciones y correcciones de la aplicación, para lo cual hace falta una documentación de las fases de diseño e implementación muy detallada. Generación Javadoc. de documentación con 4.4. Herramientas de apoyo a la documentación. JavaDoc 4.4.1. Concepto y características Entre las herramientas de apoyo a la documentación, Java tiene asociada JavaDoc. JavaDoc extrae la documentación del código y la agrupa en formato HTML. Dicha documentación del código puede ser de tres tipos: • En línea, con los caracteres // al principio • En bloque, con los caracteres /* al principio y */ al final • Comentarios JavaDoc, en los que se usa /** al principio y hay un asterisco en cada línea, y siempre se colocan antes de la declaración de una clase, un método o un constructor y dentro de ellos se puede usar código HTML. Selección del proyecto del que se genera la documentación En el cuadro de la derecha se muestra una lista de etiquetas reconocidas por Javadoc. Selección de los métodos y atributos que se documentará Generación de Javadoc 69