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