Fig. 1
Arrastra para girar · Shift + arrastrar para desplazar · clic para desarmar
Desplázate para cambiar de página
Computer Science Principles · AP Computer Science Principles
colaboración, diseño y depuración
Los programas no se escriben de una sola vez. Se investigan, se diseñan, se construyen en borrador, se prueban y se revisan, vuelta tras vuelta, hasta que hacen lo que sus usuarios necesitan.
La figura ejecuta un proceso de desarrollo común: investigar y reflexionar, designing, prototyping and testing. La esfera roja es el trabajo en curso; en cada estación puede mandar al equipo de regreso a una fase anterior. Cada vuelta deja el programa (azul) más completo: versión 3 después de 3 vueltas.
Un proceso puede ser ordenado e intencional, siguiendo fases de un plan, o exploratorio, probando ideas y quedándose con lo que funciona. Hay muchos procesos; estas cuatro fases son comunes a la mayoría.
Este capítulo es la Gran Idea 1 de AP Computer Science Principles, Desarrollo creativo: 10–13% del examen de opción múltiple. Abarca el trabajo en equipo (1.1), qué hace un programa y con qué entradas y salidas (1.2), cómo se diseñan, construyen y documentan los programas (1.3), y cómo se encuentran y corrigen los errores (1.4). También es el trabajo de la tarea de desempeño Create, la última página del capítulo.
y las perspectivas que las mejoran
Una innovación computacional incluye un programa como parte integral de su función.
Puede ser física, como un auto autónomo; software de cómputo no físico, como un programa de edición de imágenes; o un concepto de cómputo no físico, como el comercio electrónico.
Las innovaciones se mejoran mediante la colaboración. La colaboración eficaz produce una innovación que refleja la diversidad de talentos y perspectivas de las personas que la diseñaron, y las perspectivas diversas ayudan a evitar el sesgo: un equipo cuyos miembros comparten todos una misma experiencia tenderá a construir para esa experiencia.
La figura es un equipo hipotético que enumera los casos que su aplicación debe manejar. Desarrollador A por sí solo piensa en 5 de los 12. Tres desarrolladores juntos piensan en 10. El resto viene de consultar a los usuarios: 12 de 12.
Por eso importan la consulta y la comunicación con los usuarios. La información reunida de usuarios potenciales ayuda a los desarrolladores a entender el propósito del programa desde perspectivas diversas, y a construir un programa que las incorpore por completo.
programación en parejas, herramientas en línea, habilidades interpersonales
Los grupos desarrollan innovaciones con modelos comunes de colaboración. Uno es la programación en parejas.
Dos programadores comparten una computadora. El conductor (rojo) escribe el código; el navegante (azul) revisa cada línea conforme se escribe, detecta errores y piensa a futuro. A la mitad de la figura intercambian: el papel va con el teclado, no con la persona. El programa que están escribiendo es el de la página siguiente.
Las herramientas en línea apoyan la colaboración al permitir que los programadores compartan ideas y documentos y se den retroalimentación sobre ellos, trabajen o no en el mismo lugar.
Los equipos eficaces practican habilidades interpersonales, entre ellas:
qué hace un programa, y cómo
Un programa es una colección de instrucciones de programa que realiza una tarea específica cuando la ejecuta una computadora. Un programa suele llamarse software.
total ← 0 REPEAT 3 TIMES { n ← INPUT() total ← total + n } DISPLAY(total / 3) Un segmento de código es una colección de instrucciones de programa que forma parte de un programa: aquí, el ciclo de las líneas 2–6 (azul en la figura).
Un programa puede describirse en términos generales, por lo que hace: “muestra el promedio de tres números que escribe el usuario”. O con más detalle, por lo que hace y cómo lo hacen sus instrucciones: “asigna 0 a total; tres veces, lee un número en n y lo suma a total; luego muestra total / 3”.
Un programa debe funcionar con una variedad de entradas y situaciones. La figura lo ejecuta dos veces:
| entradas | total después del ciclo | mostrado |
|---|---|---|
| 4, 8, 9 | 21 | 7 |
| −2, 0, 5 | 3 | 1 |
Su comportamiento es cómo funciona durante la ejecución, y suele describirse por cómo interactúa con él un usuario: el usuario escribe tres números, y aparece un número.
Toda innovación tiene un propósito: resolver un problema, o seguir un interés mediante la expresión creativa. Los desarrolladores que entienden el propósito pueden desarrollar mejor el programa.
datos que entran, datos que salen, en muchas formas
Las entradas de un programa son datos enviados a una computadora para que un programa los procese. Las salidas de un programa son cualesquiera datos que un programa envía a un dispositivo.
Ambas vienen en una variedad de formas: táctil (un toque, una vibración), audio (una palabra hablada, un sonido), visual (una imagen de cámara, la pantalla) o texto. La figura envía por turnos una entrada de cada forma a un programa, y una salida de cada forma fuera de él.
La entrada puede venir de un usuario o de otros programas; la salida de texto de la parte inferior derecha va a otro programa, para el cual es una entrada.
Las entradas normalmente afectan la salida que produce un programa. Y la salida normalmente se basa en la entrada del programa o en su estado previo: los valores que tiene almacenados. Este programa lleva un conteo (azul) de las entradas que ha recibido, así que el mismo toque en la pantalla puede producir una salida distinta la segunda vez.
En el programa del promedio de la última página, las tres llamadas a INPUT() eran sus entradas, y DISPLAY envió su salida a la pantalla.
instrucciones que se ejecutan al activarse
Un evento está asociado con una acción y proporciona datos de entrada a un programa.
Los eventos se generan cuando se presiona una tecla, se hace clic con el mouse, se inicia un programa, o sucede cualquier otra acción definida que afecte el flujo de ejecución.
En la programación dirigida por eventos, las instrucciones del programa se ejecutan cuando se activan, en lugar de seguir el flujo secuencial de control. Nada se ejecuta línea tras línea desde arriba: cada evento ejecuta el procedimiento que lo maneja, y el programa espera el siguiente.
PROCEDURE onStart() { count ← 0 DISPLAY(count) } PROCEDURE onClick() { count ← count + 1 DISPLAY(count) } PROCEDURE onKeyPress() { count ← count - 1 DISPLAY(count) } La hoja de referencia del examen no tiene sintaxis de eventos, así que aquí cada manejador es un procedimiento y un entorno hipotético lo llama cuando ocurre su evento. En la figura el programa se inicia, se hace clic en el botón tres veces, se presiona una tecla y se hace clic en el botón una vez más. Los valores mostrados son 0, 1, 2, 3, 2, 3.
count pertenece a todo el programa, así que la salida de cada clic depende de los eventos anteriores.
iterativo e incremental
Un proceso de desarrollo puede ser ordenado e intencional, o de naturaleza exploratoria. Hay muchos; la mayoría usa fases de investigar y reflexionar, diseñar, crear prototipos y probar.
Un proceso iterativo requiere refinamiento y revisión a partir de retroalimentación, pruebas o reflexión a lo largo de todo el proceso. Esto puede requerir volver a fases anteriores. En la fila de abajo todo el programa existe desde la primera pasada, en borrador; cada ronda de retroalimentación (rojo) lo manda de regreso, y cada parte sale más completa.
Un proceso incremental divide el problema en piezas más pequeñas y se asegura de que cada pieza funcione antes de agregarla al todo. En la fila de arriba se construye y se prueba una pieza a la vez, y se une al todo solo cuando pasa su prueba.
Los dos no son opuestos. La mayoría de los equipos hacen ambos: construyen pieza por pieza, y revisan cada pieza, y el todo, conforme llega la retroalimentación.
requisitos, especificación, storyboard, módulos
El diseño de un programa empieza con la investigación, para determinar sus requisitos.
La investigación identifica las restricciones del programa, y las preocupaciones e intereses de las personas que lo usarán. Puede hacerse mediante surveys, pruebas con usuarios, interviews and observación directa.
Los requisitos del programa describen cómo funciona un programa, y pueden incluir una descripción de las interacciones con el usuario que debe ofrecer. La especificación de un programa define sus requisitos. Para una aplicación hipotética que reserva salas de estudio de una biblioteca: (1) el usuario elige una fecha; (2) el usuario ve las salas libres ese día; (3) el usuario reserva una y recibe un código.
La fase de diseño plantea cómo cumplir la especificación. Puede incluir:
La figura dibuja dos de ellos: un storyboard de la interfaz, una pantalla por paso, con el toque del usuario llevándolo de una pantalla a otra; y el programa organizado en módulos, uno por requisito.
y reconocimiento del código de otros
La documentación del programa es una descripción escrita de la función de un segmento de código, evento, procedimiento o programa, y de cómo se desarrolló.
Los comentarios son una forma de documentación escrita dentro del programa para que la lean las personas; no afectan cómo se ejecuta el programa. No todos los entornos de programación admiten comentarios, y la hoja de referencia del examen no tiene ninguno, así que en la figura la documentación de cada procedimiento está a su lado.
PROCEDURE average(numList) { total ← 0 FOR EACH num IN numList { total ← total + num } RETURN(total / LENGTH(numList)) } PROCEDURE isEven(n) { RETURN(n MOD 2 = 0) } average([6, 9, 3, 10]) devuelve 7. La documentación se escribe durante todo el desarrollo: la tarjeta de average crece con su código. Ayuda a desarrollar y mantener programas correctos, solo o en equipo, porque el siguiente lector (muchas veces el mismo autor, más adelante) puede ver para qué sirve cada parte.
Es importante reconocer cualquier segmento de código desarrollado en colaboración o por otra fuente. El reconocimiento puede estar en la documentación del programa, y debe incluir el origen o el nombre del autor original. En la figura, isEven (azul) viene de otra fuente, y su tarjeta lo dice.
cuándo se manifiesta cada uno
Tres programas, cada uno pensado para mostrar todas las calificaciones de [90, 75, 82]; cada uno tiene un error.
Un error de sintaxis es un error en el programa donde no se siguen las reglas del lenguaje de programación. En el primer programa, a la línea 5 le falta el paréntesis de cierre. El programa no se ejecuta en absoluto: no corre ninguna línea y no se muestra nada.
Un error en tiempo de ejecución es un error que ocurre durante la ejecución de un programa; cada lenguaje de programación define sus propios errores en tiempo de ejecución. El segundo programa suma 1 a i antes de mostrar, así que muestra 75 and 82 y luego pide scores[4]. En la hoja de referencia, un índice menor que 1 o mayor que la longitud de la lista es un error, y el programa termina.
Un error lógico es un error en el algoritmo o programa que hace que se comporte de forma incorrecta o inesperada. El tercer programa repite una vez de menos. Nada lo detiene: corrió hasta el final, pero mostró 2 de 3 calificaciones. Solo comparar su salida con la salida esperada revela el error.
scores ← [90, 75, 82] i ← 1 REPEAT LENGTH(scores) - 1 TIMES { DISPLAY(scores[i]) i ← i + 1 } Corregida, la línea 3 es REPEAT LENGTH(scores) TIMES.
un número fuera del rango
Un error de desbordamiento ocurre cuando una computadora intenta manejar un número que está fuera del rango de valores definido.
Muchos lenguajes de programación almacenan los enteros en un número fijo de bits, lo cual limita el rango de valores. Supón un lenguaje hipotético que almacena números enteros en 4 bits: el mayor que puede guardar es 1111, que es 15.
La figura cuenta hacia arriba desde 12. Cada paso invierte los bits que cambian. En 15, sumar 1 necesita un quinto bit (16 es 10000), y el almacenamiento solo tiene 4: un desbordamiento. Lo que pasa después depende del lenguaje: algunos se detienen con un error, otros conservan los bits que caben y siguen con un valor incorrecto (aquí, 0).
Los lenguajes reales usan más bits, así que sus límites son mucho mayores, pero de todos modos son límites. El lenguaje de la hoja de referencia del examen es distinto: ahí, el tamaño de un entero solo está limitado por la memoria de la computadora.
entradas definidas, salidas esperadas
Las pruebas usan entradas definidas para asegurar que un algoritmo o programa produzca los resultados esperados. Los programadores usan los resultados para corregirlo.
El requisito de un teatro hipotético: a menores de 13 años, o de 65 años en adelante, el boleto cuesta $8; todos los demás pagan $12. El requisito es lo que le dice a quien prueba qué entradas probar y qué esperar de cada una.
PROCEDURE price(age) { IF(age < 13 OR age ≥ 64) { RETURN(8) } RETURN(12) } Las buenas entradas de prueba muestran los distintos resultados esperados y se ubican en los extremos o justo más allá de ellos (el mínimo y el máximo) de los datos de entrada, donde se concentran los errores: aquí 12 y 13 a cada lado de un límite, 64 y 65 a cada lado del otro, y la edad más pequeña, 0.
| age (entrada) | esperado | real | |
|---|---|---|---|
| 0 | $8 | $8 | pass |
| 12 | $8 | $8 | pass |
| 13 | $12 | $12 | pass |
| 40 | $12 | $12 | pass |
| 64 | $12 | $8 | falla |
| 65 | $8 | $8 | pass |
La prueba con 64 falla: el código dice age ≥ 64 donde el requisito quiere decir age ≥ 65, un error lógico. Una prueba con una edad típica como 40 nunca lo habría encontrado.
rastreo, visualización, depuración, impresión de resultados
Formas eficaces de encontrar y corregir errores: casos de prueba, rastreo a mano, visualizaciones, depuradores y agregar instrucciones de salida adicionales.
findMax debe devolver el número más grande de una lista. Al probarla con [-3, -7, -2] devuelve 0, no −2. Para ver por qué, el programador agrega DISPLAY(max) dentro del ciclo (en azul): una instrucción de salida adicional.
PROCEDURE findMax(numList) { max ← 0 FOR EACH num IN numList { IF(num > max) { max ← num } DISPLAY(max) } RETURN(max) } El rastreo a mano, una fila por elemento:
| num | ¿num > max? | max después | DISPLAY muestra |
|---|---|---|---|
| −3 | false | 0 | 0 |
| −7 | false | 0 | 0 |
| −2 | false | 0 | 0 |
max nunca cambia: ningún elemento es mayor que 0. Un depurador muestra lo mismo al pausar el programa y mostrar sus variables (las celdas de la figura, una visualización de su estado). El error está en la línea 3: max empieza en 0, que es mayor que todos los elementos de una lista con puros números negativos.
La corrección es max ← numList[1]: empezar desde un elemento de la lista. Al ejecutarlo de nuevo, la salida adicional muestra −3, −3, −2 y devuelve −2. Después se quita el DISPLAY adicional.
tu propio programa y preguntas sobre él
La tarea de desempeño Create es este capítulo puesto en práctica: un programa de tu elección, desarrollado con el proceso, la documentación y las pruebas de 1.1–1.4.
Entregas tres cosas en el AP Digital Portfolio: el código de tu programa, un video de su ejecución y una Referencia Personalizada del Proyecto (PPR). Tienes al menos 9 horas de clase para hacerla. Tu programa debe incluir ciertos elementos, como listas y procedimientos.
El día del examen viene la respuesta escrita: 60 minutos, 2 preguntas sobre el código de tu propia PPR, que puedes ver mientras respondes.
La tarea y la respuesta escrita juntas valen 30% de la calificación AP; el examen de opción múltiple (70 preguntas en 120 minutos) vale el otro 70%.
Por eso las preguntas de este capítulo regresan sobre tu propio programa: cuál es su propósito y función, cuáles son sus entradas y salidas, qué probaste y con qué entradas, y qué error encontraste y corregiste.