Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

#ILRN: MP5 > UF2: OPT SW > Flashcards

UF2: OPT SW Flashcards

1
Q

Un CASO DE PRUEBA son

A

-Son los tipos de entrada que establecemos a través de unas condiciones de ejecución y unos resultados que se esperan para cumplir un objetivo.

  • Precondición (condición a cumplir por un conjunto de parámetros)
  • Postcondición (condición que cumplirá el valor devuelto)
  • Aserción (predicado, incluido código del programador).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

TÉCNICAS

para los CASOS DE PRUEBA (2 tipos)

A
  1. CAJA BLANCA (o de cristal)
  2. CAJA NEGRA (o de comportamiento)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Pruebas de CAJA BLANCA (estructurales o de cristal)

1ª Técnica para casos de prueba

A

Centrada en validar estructura interna del programa

Su funcionamiento se basa en el examen detalles procedimentales

Tendremos acceso al código fuente.

Se analizarán todas las posibilidades del código (inviable). Lo que si se puede es análisis de un conjunto de caminos independientes para crear casos de prueba

Asegurar por lo menos 1 vez se ejecuten y recorran: todos los caminos, sentencias, decisiones lógicas, bucles, estructuras de datos interna.

  • Que se ejecutan por lo menos 1 vez todos los caminos del módulo
  • Todas las sentencias sean ejecutadas al menos 1 vez.
  • Todas las decisiones lógicas se ejecuten al menos 1 vez en parte verdadera y otra en la falsa.
  • Todos los bucles sean probados en sus límites
  • Se usen las estructuras de datos internas que aseguren su validez.

Técnica: Prueba del camino básico (diagrama de grafos)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Pruebas de CAJA NEGRA (o de comportamiento)

2ª Técnica para casos de prueba:

A

Basada en requisitos funcionales, sin fijarse en el funcionamiento interno del programa.

Se realiza sobre la interfaz (no conoce la estructura interna del programa).

El Código fuente no está disponible.

Busca errores en: interfaz, en estructuras de datos y bd externas | en funcionalidades erróneas en inicio o fin de programa.

Algunas técnicas:

  • Clases de equivalencia
  • Análisis de valores límite
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

TIPOS DE ERRORES

A
  1. Errores de compilación
  2. Errores en tiempo de ejecución
  3. Errores lógicos
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Errores de COMPILACIÓN

A

Impiden la ejecución de un programa

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Errores en tiempo de EJECUCIÓN

A

Aparecen durante la ejecución del programa (normalmente cuando se pretende realizar una operación que no tiene solución, por ejemplo división por 0).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

ESTRATEGIAS DE PRUEBAS DE SOFTWARE

A
  1. Pruebas de UNIDAD (código)
  2. Pruebas de INTEGRACIÓN (diseño)
  3. Pruebas de VALIDACIÓN (requisitos)
  4. Prueba de SISTEMA (ingeniería del sistema)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Prueba de UNIDAD

Estrategias de Pruebas de Software:

A

Se CENTRA en la parte más pequeña (el módulo) tal cual está en el código fuente. (Se comprueba cada módulo para eliminar cualquier tipo de error en la interfaz o lógica interna).

El OBJETIVO es eliminar cualquier tipo de error en la interfaz o prueba lógica interna.

UTILIZA PRUEBAS de caja blanca y de caja negra.

Se realizarán pruebas SOBRE:

  • La interfaz del módulo (comprobación de integridad)
  • La estructura de datos locales (integridad)
  • Las condiciones límite (que funciona con los límites establecidos)
  • Caminos independientes de la estructura de control (asegurando por tanto que se ejecutan las sentencias al menos 1 vez)
  • Todos los caminos de manejo de errores.

​ HERRAMIENTAS usadas: JUnit, CPPUnit, PHPUnit. Pruebas unitarias con JUnit (con métodos para realizar comprobaciones

  • assertTrue(), assertFalse(),
  • assertEquals(),
  • assertNull(), assertNotNull(),
  • assertSame(), assertNotSame(),
  • fail()

Creación de pruebas con NetBeans

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Prueba de INTEGRACIÓN

Estrategias de Pruebas de Software:

A

CONSTRUYE una estructura con los módulos probados en la prueba anterior de unidad. -

El diseño será el foco de atención.

2 enfoques:

  • Integración no incremental (big bang): todo a la vez (se detectan muchos errores, pero la corrección es difícil).
  • Integración incremental:
    • Ascendente (empezando por los módulos más bajos).
    • Descendente (empezando por el módulo principal* y descendiendo por la *jerarquía de control).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Prueba de VALIDACIÓN

Estrategias de Pruebas de Software:

A

Prueba que realizará el usuario en el entorno final de trabajo. (Las pruebas están realizadas de tal forma que las acciones ya son visibles para el usuario)

Se consigue la validación cuando el programa funciona de acuerdo con las expectativas expuestas por el cliente y además cumpla con lo indicado en el documento de especificación de requisitos de software (ERS). - (El software ya está ensamblado y se han detectado y corregido los errores).

Se realizan pruebas de Caja Negra de 2 tipos:

  • Alfa (usuario + observación del desarrollador)
  • Beta (usuario: usuarios finales en su lugar del trabajo sin la presencia del desarrollador, el usuario registra errores y se los comunica al desarrollador después para que cree una nueva versión del producto).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Prueba de SISTEMA

Estrategias de Pruebas de Software:

A

Se probará que cada elemento esté construido de forma eficaz y funcional.

El software del sistema se prueba como un todo. - Su misión es ejercitar en profundidad el software.

Tipos:

  • Recuperación (se fuerza el fallo del sw y se comprueba la recuperación del sistema se realiza correctamente).
  • Seguridad (se comprueba que el sistema esté protegido frente a acciones ilegales).
  • y Resistencia (Stress): se lleva el sistema al límite de los recursos, sometiéndose a cargas masivas (objetivo: comprobar los extremos del sistema).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Pruebas de código:

A

Ejecución del programa para localizar errores.

Se comienza para su ejecución con varias entradas y una serie de condiciones de ejecución y observamos y registramos los resultados al compararlos con los resultados que esperamos - comprobaremos si el resultado es el esperado o no y porque).

Encontramos 3 tipos de pruebas:

  • Prueba del camino básico
  • Partición o clases de equivalencia
  • Análisis de valores límite
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

PRUEBA DEL CAMINO BÁSICO

(Pruebas de código)

A

Técnica que mediante prueba, permite obtener la medida de la complejidad del sistema.

A partir de esta medida se puede definir un conjunto de caminos de ejecución.

Para obtener esta medida de complejidad utilizaremos la técnica de representación de GRAFO DE FLUJO.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Grafo de flujo

PRUEBA DEL CAMINO BÁSICO (Pruebas de código)

A

Cada CÍRCULO (nodo) representa 1 o más bifurcaciones (se enumeran en el diagrama.

Las FLECHAS del grafo se llaman aristas o enlaces (representan el flujo del control) terminarán en un nodo aunque no tenga ninguna sentencia procedimental.

Las REGIONES son áreas que estarán delimitadas por aristas y nodos (el área exterior del nodo es otra región más).

El nodo predicado contendrá una condición (salen 2 aristas dependiendo de esa condición)

  • Secuencial
  • IF condición ELSE
  • IF condición AND
  • IF condición OR
  • Hacer mientras
  • Repetir hasta
  • Control múltiple (Case Switch)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Secuencial

(Grafo de Flujo)

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

IF Condición ELSE

(Grafo de Flujo)

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

IF Condición AND

(Grafo de Flujo)

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

IF Condición OR

(Grafo de Flujo)

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Hacer mientras

(Grafo de Flujo)

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Repetir hasta

(Grafo de Flujo)

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Condicional múltiple (Case/Switch)

(Grafo de Flujo)

A
23
Q

Complejidad ciclomática

A

Métrica del software que nos proporciona una medida cuantitativa de la complejidad lógica de un programa. -

Establece el número de casos de prueba que deberán ejecutarse para que las sentencias sean ejecutadas al menos 1 vez.

  • V(G) = Número de regiones del grafo
  • V(G) = Aristas - Nodos + 2
  • V(G) = Nodos predicados + 1 COMPLEJIDAD

CICLOMÁTICA | EV. DEL RIESGO -

  • Entre 1 y 10 | Programas o métodos sencillos (sin mucho riesgo).
  • Entre 11 y 20 | Programas o métodos más complejos (riesgo moderado).
  • Entre 21 y 50 | Programas o métodos complejos (alto riesgo).
  • Mayor que 50 | Programas o métodos no testeables, (muy alto riesgo).

OBTENCIÓN DE LOS CASOS DE PRUEBA: Último paso de la prueba del camino básico (consiste en construir los casos de prueba que fuerzan la ejecución de cada camino).

24
Q

PARTICIÓN O CLASE DE EQUIVALENCIA

(Pruebas de código)

A

Método de prueba de Caja Negra que divide los valores de los campos de entrada de un programa en clases de equivalencia.

Se pueden definir 2 clases de equivalencia:

> CLASES VÁLIDAS: valores de entrada válidos

> CLASES NO VÁLIDAS: valores de entrada no válidos.

25
Q

ANÁLISIS DE VALORES LÍMITE

(Pruebas de Código)

A

Pruebas complementarias a las anteriores, basadas en la hipótesis de que suelen ocurrir más errores en los valores extremos de los campos de entrada (no sólo centradas en las condiciones de entrada, sino que definen también las condiciones de salida).

26
Q

JUnit PRUEBAS AUTOMATIZADAS

A

Herramienta para pruebas automatizadas, integrada en Eclipse. Podemos utilizarla también en NetBeans.

Tipos de métodos:

27
Q

Tipos de anotaciones JUnit

A

@Before: Se utiliza esta anotación en los métodos que queramos que sean ejecutados antes de ejecutarse el método de prueba.

@After: Se utiliza esta anotación en los métodos que queramos que sean ejecutados después de ejecutarse el método de prueba.

@BeforeClass: Sólo podrá tener esta etiqueta un sólo método y se ejecutará al principio de realizar las pruebas.

@AfterClass: Sólo podrá tener esta etiqueta un sólo método y se ejecutará una vez finalizadas todas las pruebas.

28
Q

Pruebas JUnit: Para ejecutar una prueba varias veces

A

Pero con distintos valores, debemos seguir los siguientes pasos en JUnit:

  1. Añadir etiqueta: @RunWith(Parameterized.class) a la clase de prueba.
  2. Para devolver la lista de valores a testear, incluiremos en el método la etiqueta @Parameters.
29
Q

Pruebas con JUnit: Suite de pruebas

A

Para ejecutar una serie de pruebas, una detrás de otra:

  1. @RunWith(Suite.class) indicará a JUnit que es suite de pruebas.
  2. @SuiteClasses( ) indicará las clases que forman parte del conjunto de pruebas y las que se ejecutarán.
30
Q

Otras pruebas

A
  1. PRUEBAS FUNCIONALES: se definen a partir de las características descritas en la documentación y su compatibilidad con el sistema (podemos ejecutar pruebas a cualquier nivel: componentes, integración, sistema…). Son pruebas de Caja Negra (valoramos el comportamiento externo del programa).
  2. PRUEBAS ESTRUCTURALES: nos indican si las diferentes estrategias de pruebas de sw se han llevado a cabo correctamente.
  3. PRUEBAS DE REGRESIÓN: consisten en volver a probar una parte del sistema o un componente determinado, tras haber sido modificado, por tanto se realizan en componentes ya probados.
31
Q

Herramientas de depuración de código

A

Son herramientas LINTER (nos ayudan a detectar código confuso o incompatible (errores de programación del análisis sintáctico que realiza nuestro compilador)

Suelen ser herramientas que nos detectan fallos tipo de uso incorrecto de variables, bucles mal formados o cálculos erróneos.

32
Q

Calidad del software: Normas y certificaciones - Norma ISO/IEC 25000 SQuaRE

(Software Product Quality Requirements and Evaluation)

A

Que crean reglas comunes para evaluar la calidad del producto de software.

33
Q

Calidad del software: Familias de normas

A
  • 2500n División de Gestión de Calidad
  • 2501n Modelo de Calidad
  • 2502n Medición de Calidad
  • 25030n Requisitos de Calidad
  • 25040n Evaluación de Calidad
  • 25050-25099 Estándares de extensión SQuaRE
34
Q

Calidad del software:

Medidas de calidad del software

A
  • n1: número de operadores únicos.
  • n2: número de operandos.
  • N1: número total de ocurrencias de operadores.
  • N2: número total de ocurrencias de operandos.
35
Q

Calidad del software:

Cálculos a realizar

A
  1. Longitud: N= N1 + N2 Medida del tamaño del programa
  2. Volumen: N*logz(n) Donde n=n1+n2 Si tenemos 2 programas con la misma longitud(N) pero uno de ellos tiene mayor número de operandos y operadores únicos será más difícil de entender y mantener y tendrá mayor volumen.
  3. Dificultad: D=(n1*N2)(n2*2) La dificultad es directamente proporcional al número de operadores únicos de un programa, si los mismos operando se utilizan varias veces dentro del programa será más propenso a tener errores.
  4. Esfuerzo: E=V*D El esfuerzo por entender un programa o mantenerlo es directamente proporcional al volumen del programa y a su nivel de dificultad.
  5. Nivel: L=1/D El nivel de un programa es inversamente proporcional a su dificultad, un programa de bajo nivel es más propenso a tener errores.
  6. Otros:
    1. Número de solicitudes para el mantenimiento correctivo: si hay un aumento de reporte de fallos, quiere decir que se han introducido más errores de los que se han arreglado, por tanto el mantenimiento es más costoso.
    2. Tiempo requerido para hacer un análisis del producto: indica el número de componentes del sistema que se ven afectados (si el número es alto, el mantenimiento será costoso).
    3. Tiempo requerido para poder implementar los cambios: tiempo para modificar el aplicativo y su documentación (si este tiempo es alto el mantenimiento será costoso).
    4. Número de peticiones de cambio: un aumento de esas solicitudes hará nuestro aplicativo muy difícil de mantener.
36
Q

Refactorización

A

Nos va a permitir optimizar un código que se ha escrito previamente, realizando cambios en la estructura interna sin que afecten al comportamiento final del producto.

Deben de ir realizándose a medida que vamos realizando el código.

Objetivo: limpiar el código para que se entienda mejor y se pueda modificar de forma más fácil (lo que permite una mejor lectura y sencillez de mantenimiento).

Las bbdd y las interfaces son conflictivas (por la migración de estructuras y datos).

Los IDE (como Eclipse) soportan refactorización. - Antes de refactorizar hay que definir muy bien los casos de prueba (una buena colección). Recomendable que sean casos de prueba automáticos. Que deben poder ser ejecutados de forma independiente.

Optimizar el código no es factorizar (ambos métodos optimizan el código sin cambiar su funcionalidad, pero optimizar suele significar introducir dificultad en el código).

Importancia de las pruebas a la hora de refactorizar: donde las pruebas unitarias juegan un papel importante en el desarrollo del sw (nos previenen de las pruebas de regresión, reducen la complejidad, facilita la lectura, favorece la detección de errores…)

37
Q

Refactorización:

Bad Smells

(Síntomas para refactorizar)

A
  • CÓDIGO DUPLICADO (duplicated code): principal razón para refactorizar.
  • MÉTODOS MUY LARGOS (long method): debemos dividirlos para reutilizarlos.
  • CLASES MUY GRANDES (large class): si una clase es muy grande, tendrá muchas responsabilidades con demasiados atributos y métodos, debemos crear clases más pequeñas y bien delimitadas.
  • LISTA DE PARÁMETROS EXTENSA (long parameter list): las funciones deben tener el mínimo número de parámetros posible o de lo contrario surgen problemas de encapsulación.
  • ENVIDIA DE FUNCIONALIDAD (feature envy) (un método utiliza más elementos de una clase que de la propia - para solucionarlo ha de cambiar el método de clase).
  • CLASE SOLO DE DATOS (data class): clase que sólo tiene atributos y métodos de acceso.
  • LEGADO RECHAZADO (refused bequest). (subclases que utilizan características de superclase, lo que puede inducir a un error en la jerarquía de clases).
  • CAMBIO DIVERGENTE (divergent change) una clase se puede modificar por diferentes motivos que no tienen porque estar relacionados.
  • CIRUGÍA A TIRO PISTOLA (shotgun surgery) (“tocar” una clase implica “tocar” muchas otras) cambios adicionales realizados después de modificar una clase para compatibilizar el cambio.
38
Q

Refactorización con Eclipse

A

Con el IDE sobre la clase | clic con el botón secundario | menú | Refactor | Opciones del menú de refactorización

39
Q

Refactorización con Eclipse:

Métodos más comunes

A
  • Rename: cambia el nombre de cualquier identificador de java (de las opciones mas utilizadas).
  • Move: se mueve la clase de un paquete a otro (se mueve el archivo java y todas las referencias).
  • Extract Interface: nos permite escoger los métodos de una clase para crear una interfaz (una interfaz es una plantilla que define los métodos pero no los desarrolla, serán las clases de la interfaz las encargadas).
  • Extract Superclass: permite extraer una superclase.
  • Pull up: permite pasar un método de una subclase (clase hija) a una superclase.
  • Pull down: permite pasar un método de una superclase a una subclase.
  • Extract Constant: convierte en constante un número o cadena, con el objetivo de modificar el valor literal en un único lugar.
  • Extract Local Variable: se asigna una expresión a una variable local.
  • Convert Local Variable to Field: convierte una variable local en un atributo privado de la clase.
  • Extract Method: convierte un bloque de código en un método (no debe llevar llaves abiertas, patrón muy útil cuando detectamos bad smells en métodos muy largos o códigos que se repiten).
  • Change Method Signature: permite cambiar la firma de un método (su nombre y parámetros).
  • Inline: nos ajusta una referencia a una variable o método con la línea en la que se utiliza para conseguir así una única línea de código.
  • Member Type to Top Level: permite convertir una clase anidada en una clase de nivel superior con su propio archivo de Java.
  • Convert Anonymous Class to Nested: permite convertir una clase anónima a una clase anidada de la clase que la contiene (una clase anónima se caracteriza por:
    • Utilizar la palabra new seguida por la definición entre llaves.
    • Usar la palabra new seguida del nombre de la clase que hereda (sin extends) y la d_efinición de la clase entre llaves_.
    • Utilizar la palabra new seguida del nombre de la interfaz (sin implements) y la definición de la clase anónima entre llaves.
40
Q

Patrones de diseño

A

Una solución que se puede replicar en los desarrollos de sw.

Son descripciones de como poder afrontar un problema en diferentes situaciones.

Estructura de un patrón:

  • Nombre
  • Descripción resumida del problema
  • La solución
  • Creacionales
41
Q

Control de versiones

A

Es la capacidad de poder recordar todos los cambios que se han realizado tanto en la estructura de directorios como en el contenido de los archivos.

Puede ser muy útil para recuperar carpetas, archivos o algún proyecto en un momento dado del desarrollo. Es necesario saber qué cambios se hacen, quién los hace y cuándo se realizan.

42
Q

Control de versiones: Conceptos

A
  • REPOSITORIO: Lugar donde se almacenan los datos y cambios realizados.
  • REVISIÓN O VERSIÓN: Versión concreta de los datos almacenados. La última versión se identifica como HEAD.
  • ETIQUETAR o ROTULAR (tag): Las etiquetas se crean para localizar o recuperar en cualquier momento una versión concreta.
  • TRONCO (trunk): Línea principal del desarrollo del proyecto.
  • RAMA (Branch): Copias de carpetas, archivos o proyectos. Se pueden crear ramas para la creación de nuevas funcionalidades o comprobación de errores.
  • DESPLEGAR (checkout): Copia del proyecto, archivo y carpetas en el repositorio del equipo local.
  • CONFIRMAR (Commit o check-in): Se realiza cuando se confirman los cambios realizados en el repositorio local para incorporarlos al repositorio.
  • EXPORTACIÓN (export): Similar al Checkout pero no se vincula la copia con el repositorio.
  • IMPORTACIÓN (import): Subida de carpetas y archivos al repositorio.
  • ACTUALIZAR (update): Se realiza cuando se desea integrar los cambios realizados en el repositorio de la copia del trabajo local.
  • FUSIÓN (merge): Se unen cambios realizados sobre uno o varios archivos en una única revisión. Se suele realizar cuando existen varias ramas y es necesario unir los cambios realizados.
  • CONFLICTO Suele ocurrir cuando dos usuarios crean una copia local (checkout) y uno de ellos hace un cambios y envía un commit, y sin que el otro haga un update, hace también cambios e intenta hacer por su parte un commit. En ese momento se produce un conflicto pues el sistema es incapaz de fusionar.
  • RESOLVER CONFLICTO: Actuación del usuario para atender un conflicto entre diferentes cambios al mismo documento.
43
Q

Control de versiones: Tipos de herramientas

A

GIT: herramienta de código libre diseñada para grandes y pequeños proyectos. -

Subversión: en Eclipse. VisualSVN con Eclipse Marketplace (una vez instalado Show View - Others - SVN - SVN Repositories).

Operaciones con este:

  • Check Out,
  • Check Out As,
  • Synchronize(Team Synchronizing).

El conflicto se produce cuando 2 usuarios modifiquen el mismo archivos del repositorio y las mismas líneas del archivo. Para resolver una vez recogidos los cambios hacer Mark as Merged.

44
Q

Documentación

A

Es el texto escrito que acompaña a los proyectos. Es un requisito importante en un proyecto comercial, ya que el cliente querrá que se documente las distintas fases del proyecto

45
Q

Documentación:

Tipos

A
  1. De las especificaciones
  2. Del diseño
  3. Del usuario final
46
Q

Documentación:

De la especificaciones

A

Sirve para comprobar que tanto las ideas del desarrollador como las del cliente son las mismas, ya que sino el proyecto no será aceptable.

Según la norma IEEE 830 esta documentación deberá contener:

  • INTRODUCCIÓN: se explican los fines y objetivos del software.
  • DESCRIPCIÓN de la información: descripción detallada, incluyendo hardware y software.
  • Descripción FUNCIONAL: detalla cada función del sistema. (Programa: Rational Rose)
  • Descripción DEL COMPORTAMIENTO: explica cómo se comporta el software ante sucesos externos e internos.
47
Q

Documentación:

del diseño

A

En este documento se describe toda la estructura interna del programa, formas de implementación, contenido de clases, métodos, objetos, etc

48
Q

Documentación:

Del Código fuente

A

Durante el desarrollo del proyecto se debe ir comentando en el código fuente cada parte, para tener una mayor claridad de lo que se quiere conseguir en cada sección.

49
Q

Documentación:

Del usuario final

A

Documentación que se entrega al cliente en la que se describe cómo usar las aplicaciones del proyecto.

50
Q

Documentación

del código fuente

A

La documentación del código del programa también es fundamental para que todo el equipo pueda realizar funciones de actualización y reparación de errores de manera mucho más sencilla.

Esta debe describir lo que se está haciendo y por qué.

Hay 2 reglas que no se deben olvidar:

  • Todos los programas poseen errores y es cuestión de tiempo que se detecten.
  • Todos los programas sufren modificaciones a lo largo de su vida.

Al realizar las modificaciones es necesario que el código esté bien documentado para que otro programador ajeno localice los cambios que quiere realizar.

Al documentarlo, habrá que explicar lo que realiza una clase o un método y por qué y para qué lo hace.

Existen muchas herramientas como pueden ser PHPDoc, phpDocumentor, Javdoc o JSDoc, el javadoc para JavaScript.

51
Q

Javadoc

A

Es una herramienta de Java que sirve para extraer y generar documentación básica para el programador a partir del código fuente en formato HTML.

Los tipos de comentario para que genere la documentación son:

  • Comentarios en línea: comienzan con los caracteres “//” y terminan en la misma línea.
  • Comentarios tipo C: comienzan con “/*” y terminan con “*/”. Pueden contener varias líneas.
  • Comentarios de documentación Javadoc: se colocan entre delimitadores /**…*/, podrán agrupar varias líneas y cada línea irá precedida por un *.

Deberá colocarse antes de la declaración de una clase, un campo, un método o un constructor.

Podrá contener etiquetas HTML y los comentarios están formados por dos partes: una descripción seguida de un bloque de tags.

52
Q

Las etiquetas de Javadoc

A

Van precedidas por @ y las más utilizadas son:

  • @author: Autor de la clase. Sólo para clases.
  • @version: Versión de la clase. Sólo para clases.
  • @see: Referencia a otra clase.
  • @param: Descripción del parámetro. Una etiqueta por cada parámetro.
  • @return: Descripción de lo que devuelve. Sólo si no es void.
  • @throws: Descripción de la excepción que puede propagar. Habrá una etiqueta throws por cada tipo de excepción.
  • @since: Número de versión de la que existe el módulo.
53
Q

Generar la documentación

A

Casi todos los entornos de desarrollo incluyen un botón para poder configurar Javadoc.

Para hacerlo desde Eclipse, abrimos el menú Project y elegimos el botón Generate Javadoc.

En la siguiente ventana nos pedirá la siguiente información:

  • En Javadoc command se indicará dónde se encuentra el fichero ejecutable de Javadoc, el javadoc.exe (normalmente en el JDK en la carpeta Bin).
  • En los cuadros inferiores elegiremos el proyecto y las clases a documentar.
  • Elegimos la privacidad de los elementos. Con Private se documentarán todos los miembros públicos, privados y protegidos.
  • Para finalizar, se indica la carpeta de destino en la que se almacenará el código HTML.

Pulsar en Next, en la siguiente ventana poner el título del documento html que se genera, y elegir las opciones para la generación de las páginas HTML. Como mínimo se seleccionará la barra de navegación y el índice.

#ILRN: MP5 (5 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions