JF 3 4 SG Esp

1
Java Fundamentals
3-4
Desarrollar y probar una aplicación
Copyright © 2022, Oracle y/o sus filiales. Oracle, Java y MySQL son marcas comerciales
registradas de Oracle y/o sus filiales. Todos los demás nombres pueden ser marcas
comerciales de sus respectivos propietarios.
2
Objetivos
• En esta lección se abordan los siguientes objetivos:
−Demostrar las estrategias de prueba del programa
−Reconocer las fases para el desarrollo de una aplicación de
software
JF 3-4 Copyright © 2022, Oracle y/o sus filiales. Oracle, Java y MySQL son marcas comerciales
Desarrollar y probar una aplicación registradas de Oracle y/o sus filiales. Todos los demás nombres pueden ser marcas 3
3
Programar estrategias de prueba
• Un programador prueba un programa muchas veces
durante el transcurso de su desarrollo, a fin de
garantizar su correcto funcionamiento
• Programar estrategias de prueba:
−Realice pruebas con frecuencia después de cada método, o
una secuencia de métodos
−Si aparecen errores, corríjalos
−Ejecute el programa para observar cómo los métodos hacen
que se muevan los objetos
−Continúe agregando métodos y realice los ajustes necesarios
Las pruebas son un aspecto importante en el desarrollo de software. Debe probar

constantemente el programa mientras escribe el código fuente, realiza la compilación y la
ejecución. Contar con una estrategia de prueba clara puede aumentar significativamente la
calidad del software.
Probará personalmente algunos aspectos del código, pero otros aspectos serán probados por
terceros. Contar con otros usuarios, especialmente aquellos a los que está destinado el
software, y probar el programa lo ayudarán a evitar errores y a aumentar la funcionalidad de su
software.
4
Compilación y depuración
• Todos los caracteres en el código fuente son
importantes
• Si falta algún carácter o es incorrecto, el programa
puede fallar
• En Greenfoot, la compilación resalta los errores de
sintaxis e indica los pasos necesarios para corregirlos
• Esto permite desarrollar técnicas de programación
correctas
Los bugs son errores en el código de un programa informático. Para
depurar un programa, el programador lee los mensajes de error que
proporciona Greenfoot.
Después, corrige esos errores en la sintaxis. Las pruebas pasarán entonces
a la lógica del código.
Recuerde que compilar software de forma correcta no significa que esté libre de errores. Solo
significa que la sintaxis es correcta.
5
Pasos para depurar el programa
• Si no hay ningún error, aparece el mensaje "Class
compiled – no syntax errors"
• Si hay errores, se resalta la sintaxis incorrecta y un

mensaje intenta explicar el error
6
Claves para reconocer errores de sintaxis Java
1 Localice el principio y el final de un método.
2 Asegúrese de que aparecen las llaves de apertura { y cierre }.
3 Asegúrese de que aparecen todos los paréntesis abiertos
( y cerrados ).
4 Asegúrese de que todas las líneas de código finalizan con un punto y
coma.
5 Asegúrese de que la ortografía y el uso de mayúsculas y minúsculas
en los nombres es correcto.
6 Revise todas las notaciones de puntos (por ejemplo,
System.out.println).
7 Asegúrese de que los caracteres de grafía similar son correctos
(número 1 y letra i).
8 Asegúrese de que todas comillas son dobles " no simples '.
Un sangrado de código correcto mejorará significativamente la legibilidad del código. Esto

permite localizar errores como los mencionados anteriormente de una forma mucho más
sencilla y en menos tiempo.
7
Diseño automático
• Auto-Layout es una función muy útil en el editor de
código de Greenfoot
• Comprobará que esta función estructura
automáticamente el código y es una magnífica
herramienta que permite encontrar los paréntesis y
corchetes que faltan
El diseño automático realizará un sangrado del código entre corchetes. Esto demuestra las
técnicas de diseño óptimas para que el código sea más legible. Para Greenfoot no supone
ningún problema que se escriba todo el código en una línea, pero intentar buscar errores en el
código se convierte en una tarea muy difícil. Asimismo, el hecho de intentar leer cómo funciona
el código se convierte en una tarea muy tediosa.
8
Fases para desarrollar una aplicación
1. Analizar el problema a resolver o la tarea a realizar
2. Diseñar la solución, que es habitualmente un juego
en Greenfoot
3. Desarrollar el juego en Greenfoot
4. Probar el juego para garantizar que funciona y que
cumple los requisitos de su análisis y diseño
5. El desarrollo de un juego en Greenfoot sigue los
mismos pasos que el desarrollo de una aplicación de
software
La planificación del juego antes iniciar la codificación le ahorrará mucho tiempo. Algunos juegos
sencillos requerirán muy poca planificación, pero a medida que aumenta la complejidad del
juego también aumenta la necesidad de utilizar técnicas de planificación adecuadas.
9
Fase de análisis
• En la fase de análisis, determine el problema que
resolverá el juego o la tarea que realizará utilizando un
análisis orientado al objeto
En el análisis orientado a objetos, los programadores de Java

analizan un problema y, a continuación, crean objetos para generar
un sistema, o más concretamente, para resolver el problema.
La identificación de los objetos necesarios en el software lo ayudará a determinar el número de

subclases necesarias en la clase Actor. Aunque normalmente tendremos un nivel de clases en
Actor, en programas de mayor envergadura podemos tener varios niveles con Actor -> subclase
-> subclase, donde las clases comparten campos y métodos comunes.
10
Tareas de la fase de análisis
• Identificar un problema para resolverlo
• Escribir una breve sentencia del ámbito que indique el tipo
de solución (juego) que resolverá el problema
• Reunir los requisitos de los destinatarios
• Se trata de las personas que con mayor probabilidad
jugarán al juego
• Identificar y describir objetos en el juego
− Objetos físicos (automóvil, persona, árbol)
− Objetos conceptuales ( "no físicos"), el temporizador que cuenta el
tiempo restante del juego
− Atributos de todos los objetos, tales como el color, el tamaño, el
nombre y la forma
− Operaciones que realizan los objetos (mover, girar, comer otros
objetos)
La recopilación de la información necesaria lo ayudará a planear mejor una solución.
11
Ejemplo de análisis
Elemento de análisis Descripción
Deseo crear un juego para enseñar a los alumnos a
Dominio de problemas
controlar una abeja con las teclas del cursor.
Debe resultar sencillo para los niños de todas las edades.
Requisitos del jugador
Es necesario que el jugador disponga de un teclado.
1 objeto Abeja que capturará moscas.
Varios objetos Mosca.
Objetos
1 objeto Araña que capturará las moscas y la abeja.
1 mundo con un fondo de color claro.
Abeja: Mover, girar y capturar moscas.
Mosca: Mover aleatoriamente por la pantalla.
Operaciones de
Recuento de ciclo de vida: Realice un recuento regresivo
objetos
de 3 a 1 cada vez que una araña capture a la abeja.
Antecedentes: No hacer nada.
La definición de las acciones de un objeto le proporcionará la base de los métodos y campos

necesarios en sus subclases.
12
Condiciones previas y posteriores del análisis
• Capture información para permitir la prueba de:
Elemento a probar Ejemplo

Condiciones previas y posteriores del Valores inicializados de la variable frente a
juego. valores tras la ejecución del programa.
Tiempos de ejecución anticipados y Los ratios de ejecución pueden variar en
ratio de ejecución de comparación función de la varianza de tamaño de la
según un juego de condiciones. memoria de la computadora.
Resultados esperados en materia de Un contador de ciclos de tres producirá tres
ejecución de la sentencia. nuevas variables.
Representaciones numéricas y
Valor máximo de un entero.
limitaciones.
Las pruebas pueden planificarse antes de que se haya iniciado cualquier codificación. Tiene la
ventaja de hacer que los programadores piensen en los elementos que se van a probar
mientras comienzan a codificar una solución.
13
Fase de diseño
• La solución que diseñe tendrá el formato de un juego
de Greenfoot que pueden jugar los destinatarios
• Diseñe el juego en un storyboard textual que planee
los algoritmos o métodos que los objetos realizarán en
respuesta a los comandos del teclado o a los clics del
mouse
Un diseño óptimo le permite pensar en el modo en el que actuarán e interactuarán todos los
objetos. Resulta sencillo al escribir código que no siga un diseño para quedar atrapado solo con el
problema actual y no con la imagen más grande. Puede dar lugar a soluciones codificadas de
forma deficiente.
14
Ejemplo de storyboard textual
• Este storyboard textual en la siguiente diapositiva
describe un juego sencillo en el que se controla una
abeja para poner a prueba y capturar moscas mientras
esquiva a una araña
• La araña también capturará moscas
• Obtendrá puntos por cada mosca capturada y perderá
una vida cada vez que la araña capture a la abeja
• El juego termina cuando se agotan las vidas
15
• Al hacer clic en el botón Run, la abeja avanzará de
forma continua
• El jugador utiliza las teclas de flecha en el teclado para
controlar los movimientos a izquierda y derecha de la
abeja
• Cuando la abeja está en el mismo cuadro que una
mosca que se mueve de forma aleatoria, se captura y
se elimina del juego y se agrega otra mosca
El storyboard textual se completa cuando se entrega a cualquier programador y otros usuarios

obtendrían resultados muy similares. Si todos ellos crearon soluciones completamente
diferentes, significa que el storyboard era el que estaba incompleto.
Para probar el storyboard, puede entregárselo a tres personas y hacer que estas le expliquen el
funcionamiento del juego. Si existen grandes diferencias en sus explicaciones, el storyboard
requiere información adicional.
16
• Una araña se moverá de forma aleatoria por la pantalla
• Si la araña captura a una abeja, el usuario pierde una
vida
• Si captura a una mosca, se elimina del juego
• El juego termina cuando al usuario no le quedan vidas
El storyboard textual se completa cuando se entrega a cualquier programador y otros usuarios

obtendrían resultados muy similares. Si todos ellos crearon soluciones completamente
diferentes, significa que el storyboard era el que estaba incompleto.
Para probar el storyboard, puede entregárselo a tres personas y hacer que estas le expliquen el
funcionamiento del juego. Si existen grandes diferencias en sus explicaciones, el storyboard
requiere información adicional.
17
Fase de desarrollo
• Tras finalizar el storyboard, desarrolle el juego en
Greenfoot
• Consulte el storyboard para determinar los métodos
que necesita programar
En esta diapositiva, no hemos escrito ningún código. Solo hemos creado las clases necesarias y agregado
instancias de estas clases a nuestro escenario para hacernos una idea del aspecto que va a tener el
programa.
18
Fase de pruebas
• Tras escribir una sección de código, compílela y, a
continuación, pruébela haciendo clic en el botón Run en el
entorno
• Observe el juego y, a continuación, revise el código según
sea necesario
• Para fines de control de calidad:
− Haga que otras personas prueben el juego y den su opinen
− Busque personas con características similares a las de los
destinatarios del juego
• Escriba planes de prueba que permitan:
− Examinar las condiciones previas y posteriores
− Comparar los ratios de tiempo de ejecución y los recuentos de
ejecuciones
− Probar de forma exhaustiva las limitaciones y representaciones
numéricas
Probar el programa en pequeñas etapas le permite identificar errores de forma más fácil, ya
que puede hacerse una mejor idea del punto en el que probablemente residen. Si ha escrito el
programa completo antes de probarlo, le resultará mucho más laborioso detectar el punto en
el que se pueden producir estos errores.
19
Probar límites y representaciones numéricas
Ejemplo 1
• Por ejemplo, una solución de banca requiere que se
realice el redondeo numérico de forma precisa
• Este programa podría producir resultados incorrectos si
no se ha definido el redondeo de una cifra a dos dígitos
tras una coma decimal
• La suma de un 1/2 de céntimo multiplicado por un
millón de clientes podría producir un error de
programación costoso
20
Probar límites y representaciones numéricas
Ejemplo 2
• Por ejemplo, una construcción IF en un programa
espera un valor positivo de 5 a 9 para, a continuación,
sumar ese valor a otra variable
−El programa alimenta de forma incorrecta un valor de 2 a la
variable
−Esto hace que la construcción IF falle y que la variable que
espera un cambio condicional no obtenga la cantidad
esperada, de modo que la operación de la estructura de
datos será diferente
−Este es un ejemplo del punto en el que el programa ejecutará
el resultado de la construcción condicional, incluso si no es el
correcto
21
Terminología
• Términos clave que se han utilizado en esta lección:
−Bugs
−Documentación
22
Resumen
• En esta lección, debe haber aprendido a:
−Demostrar las estrategias de prueba del programa
−Reconocer las fases para el desarrollo de una aplicación de
software
23
24

JF 3 4 SG Esp

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

JF 3 4 SG Esp

Cargado por

Copyright:

Formatos disponibles

1

Las pruebas son un aspecto importante en el desarrollo de software. Debe probar

• Si hay errores, se resalta la sintaxis incorrecta y un

Un sangrado de código correcto mejorará significativamente la legibilidad del código. Esto

En el análisis orientado a objetos, los programadores de Java

La identificación de los objetos necesarios en el software lo ayudará a determinar el número de

La recopilación de la información necesaria lo ayudará a planear mejor una solución.

La definición de las acciones de un objeto le proporcionará la base de los métodos y campos

Elemento a probar Ejemplo

El storyboard textual se completa cuando se entrega a cualquier programador y otros usuarios

El storyboard textual se completa cuando se entrega a cualquier programador y otros usuarios

También podría gustarte