PRACTICA GREENFOOT

1. Fecha de la versión: Agosto de 2015
Actualizaciones:

3. 3

4. 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

5. Recuerde que compilar software de forma correcta no significa que esté libre de errores. Solo significa que
la sintaxis es correcta.
5

6. 6

7. 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

8. 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

9. 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

10. 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

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

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

13. La definición de las acciones de un objeto le proporcionará la base de los métodos y campos necesarios en
sus subclases.
13

14. 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.
14

15. 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.
15

16. 16

17. 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

18. 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.
18

19. En la captura de pantalla anterior, no hemos escrito ningún código. Solo hemos creado las clases que
necesitamos y agregado instancias de estas clases a nuestro escenario para hacernos una idea del aspecto
que va a tener el programa.
19

20. 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.
20

21. 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.
21

22. 22

23. 23

24. 24

25. 25