DESPLIEGUE - APP - WEB - UF4

En phpDocumentor, ¿En qué marca se muestra la informacion en la documentacion interna pero no deberia aparecer en la documentacion publica?. @global. @internal. @see. @example.

A la hora de realizar la documentacion, la interfaz: Indicara el funcionamiento de cada componente o funcion. Es el canal a través el cual el usuario (del nivel especificado) se comunica con un software de nivel más bajo. Se indicará por qué se ha decidido realizar cada acción de la aplicacion. Será útil para quienes depuren o actualicen los bloques de codigo de la aplicacion.

A la hora de realizar la documentación, ¿La toma de decisiones?. Se indicará el por que se ha decidido realizar cada acción de la aplicación. Es el canal a través el cual el usuario (del nivel especificado) se comunica con un software de nivel más bajo. Será útil para quienes depuren o actualicen los bloques de codigo de la aplicacion. Indicara el funcionamiento de cada componente o función.

¿Qué es el Git?. Es un control de versiones de codigo cerrado. Un lenguaje de programacion. Fue creado en los años 90. Un control de versiones escrito en C.

La importancia de mantener un control de versiones es básicamente... Tener mas servicios web que ofrecer a nuestros clientes. Disponer el código en un servidor público al alcance de todos. Disponer de un control de versiones, ordenado y común para un equipo de desarrollo. Facilitar que los programadores se peleen por el codigo que desarrollan.

¿Que es Javadoc?. Es una utilidad Oracle para la generación de documentación de APIs en formato HTML a partir de código fuente PHP. Es una utilidad Oracle para la generación de documentación de APIs en formato HTML a partir de código fuente Java. Es un utilidad exclusiva de Linux para generar documentación. Es una utilidad de tomcat para el acceso a servidor.

Un sistema de control de versiones. Permiten comparar versiones. Permite realizar copias de las distintas versiones de un directorio. Se encargan de realizar copias de las distintas versiones de un directorio. Todas las respuestas son correctas.

¿Sobre que entorno trabajaremos al instalar Javadoc?. Eclipse. Notepad. VisualStudio. Ubuntu.

¿Que es phpDocumentor?. Un estándar para documentar clases en perl. Un estándar que se usa para documentar el codigo en PHP. Un estándar para documentar clases en Visual Code. Un estándar para documentar clases en Visual Studio.

¿Qué caracteristicas nos proporciona Javadoc a la hora de comentar?. Las etiquetas se situarán al final de la linea. Los comentarios empezarán con /* y terminaran con **/. Las etiquetas que comiencen con @. Ninguna respuesta es correcta.

¿De que forma pueden encontrarse los archivos en Git?. Confirmado, modificado y preparado. Modificado y conformado. Preparado y modificado. Confirmado y preparado.

¿Qué comando ejecutaremos para comprobar que git se ha instalado correctamente?. git -confirm. git -version. git -revision. git -control.

En el control de versiones ¿Qué nos da visión en un momento dado del estado de archivos y directorios?. Repositorio. Revisión. Copia de trabajo. Rama de trabajo.

¿Cuál de las siguientes expresiones no es una función que podamos realizar en el sistema de control de versiones?. Controlar los diferentes niveles de la capa OSI. Actualizar una copia local al servidor. Realizar cambios en los ficheros. Mantener las distintas ramas del proyecto.

¿Qué herramientas nos permitirán generar documentación automática a partir de código fuente Java?. phpDoc. Ninguna de las respuestas es correcta. JavaDocumentor. Javadoc.

A la hora de realizar la documentación, ¿debemos tener en cuenta?. La implementacion que Indicara el funcionamiento de cada componente o funcion. La interfaz, Es el canal a través el cual el usuario (del nivel especificado) se comunica con un software de nivel más bajo. Toma de decisiones: Se indicará por qué se ha decidido realizar cada acción de la aplicacion. Todas son correctas.

¿De qué dos formas podemos trabajar con una herramienta de generacion de documentacion?. Solo en entorno web. Ninguna respuesta es correcta. Tanto en linea de comandos, como en entorno web. Sólo en linea de comandos.

¿Es necesario transcribir la implementación fuera del código?. La implementación es necesaria en un manual de uso, pero la interfaz no. La implementación no es necesaria, pero la interfaz si seria recomendable para un manual de uso. Todo hay que documentarlo. Ninguna es correcta.

¿Qué es PHPdocumentor?. Un estándar que se usa para documentar el código en PHP. Un estándar que es usa para documentar el código en Visual Studio. Un estándar que es usa para documentar el código en Visual Code. ninguna es correcta.

¿En que se basan los sistemas de control centralizados?. Los archivos están en varios servidores. Se emplea cuando hay un solo desarrollador trabajando en un proyecto. Un desarrollador sabrá en que esta trabajando el resto de las personas del proyecto. Todas son correctas.

¿Qué herramientas nos proporciona javadoc a la hora de comentar?. Las etiquetas se situaran al final de la linea. Los comentarios empezarán con /** y terminaran con */. Los comentarios empezarán con /* y terminaran con **/. Ninguna respuesta es correcta.

en phpDocumentor ¿Qué marca debemos utilizar para documentar a nivel de fichero. @package. @file. @deprecated. @access.

En el control de versiones, ¿qué es un conjunto ordenado de revisiones?. Un repositorio. Un tronco. Una rama de trabajo. Un parche.

¿Cuál es la relación entre una "Copia de trabajo" y una "Rama de trabajo" en un sistema de control de versiones, según los conceptos proporcionados?. Una copia de trabajo es una versión específica de una rama de trabajo, lo que facilita la edición activa de archivos sin afectar otras ramas. Cada rama de trabajo tiene su propia copia de trabajo, garantizando que las modificaciones se realicen en un entorno aislado antes de ser incorporadas a la rama principal. La copia de trabajo es la última revisión de una rama de trabajo, permitiendo realizar modificaciones en los archivos de manera local antes de confirmar los cambios en el repositorio. Una rama de trabajo es una copia exacta de los archivos en edición activa, asegurando que todas las modificaciones se realicen en una copia independiente antes de ser fusionadas con la rama principal.

¿Cuál es el propósito principal del Directorio de Git según la información proporcionada, y cómo se diferencia del Área de Preparación en el flujo de trabajo de Git?. El Directorio de Git es la copia de una versión del proyecto, a diferencia del Área de Preparación que almacena información para la próxima confirmación. El Directorio de Git almacena metadatos y BD de objetos para el proyecto, mientras que el Área de Preparación guarda archivos modificados sin confirmar en la BD. El Directorio de Git es la carpeta que se copia al realizar la copia de un repositorio a otro, en contraste con el Área de Preparación que contiene la versión actual del proyecto. El Directorio de Git almacena instantáneas y metadatos para el proyecto, mientras que el Área de Preparación guarda archivos listos para la próxima confirmación.

¿Cuál es una de las desventajas asociadas con los sistemas de control de versiones centralizados (CVS) según el texto, y cómo se diferencia esto de los sistemas de control de versiones distribuidos (DVCS)?. La desventaja del CVS es que los desarrolladores no pueden realizar su trabajo si el servidor deja de funcionar, a diferencia de los DVCS que posibilitan la restauración de elementos del repositorio por cualquier cliente en caso de fallo del servidor. CVS presenta la ventaja de que cada desarrollador sabe en qué está trabajando el resto del proyecto, mientras que los DVCS no proporcionan información sobre el trabajo de otros desarrolladores. Una desventaja del CVS es la falta de colaboración entre desarrolladores, mientras que los DVCS permiten una replicación continua al repositorio, evitando problemas en caso de fallo del servidor central. La desventaja de los CVS es la pérdida potencial de información en caso de fallo del servidor, a diferencia de los DVCS que se centran en la descarga de la última versión de los archivos.

¿Cuál es la principal característica que distingue a los sistemas de control de versiones distribuidos (DVCS) de los sistemas de control de versiones centralizados (CVS)?. La principal ventaja de los CVS es que cada desarrollador sabe en qué está trabajando el resto del proyecto, algo que no se logra con eficacia en los DVCS debido a la replicación continua de archivos. Los DVCS permiten la colaboración eficiente entre desarrolladores, mientras que los CVS carecen de esta capacidad, afectando la coordinación del trabajo en equipo. Los CVS son propensos a fallos de servidor, lo que puede resultar en la pérdida de información almacenada, mientras que los DVCS garantizan la restauración de elementos del repositorio por cualquier cliente en caso de fallo del servidor. En los DVCS, los clientes realizan una copia completa de todos los datos en cada descarga, asegurando una replicación constante al repositorio, a diferencia de los CVS que descargan únicamente la última versión de los archivos.

¿Cuál es una de las principales características de Git en términos de almacenamiento de datos, y cómo se diferencia de otros sistemas de control de versiones mencionados en el libro?. Git realiza todas sus operaciones de forma remota, eliminando la necesidad de archivos y recursos locales, en contraste con sistemas como RCS que se basan en la copia de parches. Git almacena los datos como un conjunto de instantáneas, asegurando la eficiencia y rapidez en grandes proyectos, en contraste con sistemas como CVS que se basan en la replicación continua de archivos. La principal característica de Git es su capacidad para crear sistemas de ramificación, diferenciándose de sistemas centralizados como CVS que no ofrecen esta funcionalidad. La integridad de Git se logra mediante la verificación de cambios antes de ser almacenados, una característica ausente en sistemas como SVN, que pueden permitir cambios sin detección.

¿Qué aspecto de la documentación es crucial para quienes depuran o actualizan bloques de código en una aplicación?. La interfaz, que facilita la comunicación del usuario con el software de nivel más bajo. La comunicación remota, que permite la interacción con dispositivos externos. La implementación, que describe el funcionamiento de cada componente o función. Toma de decisiones, que explica las razones detrás de cada acción de la aplicación.

¿En qué parte del ciclo de trabajo de un sistema de control de versiones se lleva a cabo la resolución de conflictos y cuál es su función principal dentro de este proceso?. Ocurre después de la actualización local y antes de la actualización de ficheros en el repositorio, notificando a los usuarios sobre conflictos para su resolución. La resolución de conflictos ocurre durante la descarga del fichero inicial y garantiza la consistencia de versiones en el repositorio. La resolución de conflictos tiene lugar antes de la modificación de los ficheros, permitiendo identificar posibles problemas antes de realizar cambios en la copia local. Se resuelven conflictos después de la modificación de los ficheros y antes de la actualización local, asegurando una transición sin problemas entre las versiones.

¿Cuál es el flujo de trabajo recomendado en Git para realizar cambios en un proyecto, y cuál es el propósito principal del Área de Preparación en este proceso?. El proceso comienza con la preparación de archivos en el Área de Preparación, seguido por la modificación de archivos en el directorio de trabajo y finalmente la confirmación de cambios. El propósito del Área de Preparación es almacenar la copia de una versión del proyecto. El flujo de trabajo consiste en primero modificar archivos en el directorio de trabajo, luego preparar los archivos en el Área de Preparación y finalmente confirmar los cambios. El propósito del Área de Preparación es marcar archivos listos para la próxima confirmación. El flujo de trabajo implica primero confirmar cambios, luego preparar archivos y finalmente modificar archivos en el directorio de trabajo. El propósito del Área de Preparación es almacenar archivos confirmados de manera segura en la BD local. El flujo de trabajo incluye primero confirmar cambios, luego preparar archivos y finalmente modificar archivos en el Área de Preparación. El propósito del Área de Preparación es ser una copia de una versión del proyecto.

¿Cuál es la principal diferencia entre RCS (Sistema de Control de Revisiones) y CVS (Sistema de Control de Versiones Centralizado)?. RCS se destaca por la replicación continua de archivos al repositorio, garantizando la restauración en caso de fallo del servidor, a diferencia de CVS que utiliza copias completas para actualizaciones. RCS se basa en la copia de parches, permitiendo diferencias de archivos en formato especial, mientras que CVS se centra en la colaboración entre desarrolladores en un servidor centralizado. RCS y CVS comparten la misma metodología de control de versiones, siendo la única diferencia la nomenclatura utilizada para referirse a sus funciones específicas. La principal diferencia radica en que RCS facilita la colaboración entre desarrolladores en un servidor centralizado, mientras que CVS utiliza copias completas de archivos para controlar las versiones.

¿Cuál es el propósito fundamental de Javadoc en la documentación de clases Java, y por qué se enfatiza la inclusión de comentarios directamente en el código fuente?. La meta principal es crear un estándar de codificación, y se recomienda la inserción de comentarios para promover una estructura organizada en el código fuente. La principal meta es evitar la obsolescencia de la información en las clases Java, y los comentarios en el código permiten una generación eficiente de documentación en PDF. Javadoc busca facilitar la generación de documentación en HTML, y se añaden comentarios en el código para brindar claridad y coherencia en la documentación HTML generada. El propósito principal es simplificar la lectura del código, y se insertan comentarios para mejorar la estética del código fuente.

¿Cuál es la diferencia clave entre las etiquetas de bloque y las etiquetas inline en JavaDoc?. Las etiquetas de bloque y las inline son términos intercambiables y se refieren a lo mismo en la documentación JavaDoc. Las etiquetas de bloque se insertan únicamente en la descripción principal, mientras que las inline pueden usarse tanto en la descripción principal como en la sección de etiquetas. Las etiquetas de bloque se aplican solo a la descripción principal, mientras que las inline se utilizan exclusivamente en la sección de etiquetas. Las etiquetas de bloque y las inline tienen la misma funcionalidad y se pueden intercambiar en cualquier parte de la documentación.

¿Cuáles son los parámetros esenciales que se deben especificar al generar documentación mediante comentarios o etiquetas para clases y métodos en un proyecto?. La ubicación de los ficheros incluidos, el formato de salida preferido y el directorio donde se encuentra el código fuente. El formato de salida deseado, el directorio de generación de documentación y la interfaz de visualización (web o línea de comandos). La visibilidad de la documentación (pública o interna), el formato de salida y la interfaz de visualización (web o línea de comandos). El directorio del código fuente, los paquetes a documentar, el directorio de generación de documentación y la visibilidad de la documentación (pública o interna).