Fig. 1
Arraste para girar · Shift + arraste para mover · clique para desmontar
Role para virar a página
Computer Science Principles · AP Computer Science Principles
colaboração, projeto e depuração
Programas não são escritos de uma só vez. Eles são investigados, projetados, construídos de forma preliminar, testados e revistos, volta após volta, até fazerem o que seus usuários precisam.
A figura executa um processo de desenvolvimento comum: investigar e refletir, designing, prototyping and testing. A bola vermelha é o trabalho em mãos; em cada estação ele pode mandar a equipe de volta a uma fase anterior. Cada volta deixa o programa (azul) mais completo: versão 3 depois de 3 voltas.
Um processo pode ser ordenado e intencional, seguindo fases de um plano, ou exploratório, testando ideias e ficando com o que funciona. Há muitos processos; estas quatro fases são comuns à maioria deles.
Este capítulo é a Grande Ideia 1 de AP Computer Science Principles, Desenvolvimento Criativo: 10–13% da prova de múltipla escolha. Ele abrange o trabalho em conjunto (1.1), o que um programa faz e com quais entradas e saídas (1.2), como os programas são projetados, construídos e documentados (1.3) e como os erros são encontrados e corrigidos (1.4). É também o trabalho da tarefa de desempenho Create, a última página do capítulo.
e as perspectivas que as melhoram
Uma inovação computacional inclui um programa como parte integral de sua função.
Ela pode ser física, como um carro autônomo; um software computacional não físico, como um software de edição de imagens; ou um conceito computacional não físico, como o comércio eletrônico.
As inovações são aprimoradas por meio da colaboração. Uma colaboração eficaz produz uma inovação que reflete a diversidade de talentos e perspectivas das pessoas que a projetaram, e perspectivas diversas ajudam a evitar o viés: uma equipe cujos membros compartilham todos uma só experiência tende a construir para essa experiência.
A figura é uma equipe hipotética listando os casos que seu aplicativo deve tratar. Desenvolvedor A sozinho pensa em 5 dos 12. Três desenvolvedores juntos pensam em 10. O restante vem de consultar os usuários: 12 de 12.
É por isso que a consulta e a comunicação com os usuários importam. As informações coletadas de usuários em potencial ajudam os desenvolvedores a entender o propósito do programa a partir de perspectivas diversas e a construir um programa que as incorpore plenamente.
programação em pares, ferramentas on-line, habilidades interpessoais
Grupos desenvolvem inovações com modelos comuns de colaboração. Um deles é a programação em pares.
Dois programadores compartilham um computador. O piloto (vermelho) digita o código; o navegador (azul) revisa cada linha conforme ela é escrita, percebe erros e pensa adiante. No meio da figura eles trocam: o papel acompanha o teclado, não a pessoa. O programa que estão escrevendo é o da próxima página.
As ferramentas on-line apoiam a colaboração ao permitir que programadores compartilhem ideias e documentos e deem feedback sobre eles, estejam ou não na mesma sala.
Equipes eficazes praticam habilidades interpessoais, incluindo, entre outras:
o que um programa faz e como
Um programa é uma coleção de instruções que realiza uma tarefa específica quando executada por um computador. Um programa costuma ser chamado de software.
total ← 0 REPEAT 3 TIMES { n ← INPUT() total ← total + n } DISPLAY(total / 3) Um trecho de código é uma coleção de instruções que faz parte de um programa: aqui, o laço das linhas 2–6 (azul na figura).
Um programa pode ser descrito em linhas gerais, pelo que faz: “ele exibe a média de três números digitados pelo usuário”. Ou com mais detalhes, pelo que faz e como suas instruções fazem isso: “ele atribui 0 a total; três vezes, lê um número para n e o soma a total; depois exibe total / 3.”
Um programa precisa funcionar com uma variedade de entradas e situações. A figura o executa duas vezes:
| entradas | total depois do laço | exibido |
|---|---|---|
| 4, 8, 9 | 21 | 7 |
| −2, 0, 5 | 3 | 1 |
Seu comportamento é como ele funciona durante a execução, muitas vezes descrito pela forma como o usuário interage com ele: o usuário digita três números e um número aparece.
Toda inovação tem um propósito: resolver um problema ou perseguir um interesse por meio da expressão criativa. Desenvolvedores que entendem o propósito têm mais facilidade para desenvolver o programa.
dados entram, dados saem, de muitas formas
Entradas do programa são dados enviados a um computador para serem processados por um programa. Saídas do programa são quaisquer dados enviados de um programa para um dispositivo.
Ambas vêm de várias formas: tátil (um toque, uma vibração), áudio (uma palavra falada, um som), visual (uma imagem de câmera, a tela) ou texto. A figura envia uma entrada de cada forma, em sequência, para um programa, e uma saída de cada forma para fora dele.
A entrada pode vir de um usuário ou de outros programas; a saída de texto no canto inferior direito vai para outro programa, para o qual ela é entrada.
As entradas geralmente afetam a saída que um programa produz. E a saída geralmente se baseia na entrada do programa ou em seu estado anterior: valores que ele guardou. Este programa mantém uma contagem (azul) das entradas que recebeu, então o mesmo toque na tela pode produzir uma saída diferente na segunda vez.
No programa da média da última página, as três chamadas a INPUT() eram suas entradas, e DISPLAY enviava sua saída para a tela.
instruções executam quando acionadas
Um evento está associado a uma ação e fornece dados de entrada a um programa.
Eventos são gerados quando uma tecla é pressionada, um mouse é clicado, um programa é iniciado ou qualquer outra ação definida ocorre e afeta o fluxo de execução.
Na programação orientada a eventos, as instruções do programa são executadas quando acionadas, e não pelo fluxo sequencial de controle. Nada executa linha após linha a partir do topo: cada evento executa o procedimento que o trata, e o programa espera pelo próximo.
PROCEDURE onStart() { count ← 0 DISPLAY(count) } PROCEDURE onClick() { count ← count + 1 DISPLAY(count) } PROCEDURE onKeyPress() { count ← count - 1 DISPLAY(count) } A folha de referência da prova não tem sintaxe de eventos, então aqui cada tratador é um procedimento e um ambiente hipotético o chama quando seu evento acontece. Na figura, o programa é iniciado, o botão é clicado três vezes, uma tecla é pressionada e o botão é clicado mais uma vez. Os valores exibidos são 0, 1, 2, 3, 2, 3.
count pertence ao programa inteiro, então a saída de cada clique depende dos eventos anteriores.
iterativo e incremental
Um processo de desenvolvimento pode ser ordenado e intencional, ou exploratório por natureza. Existem muitos; a maioria usa fases de investigação e reflexão, projeto, prototipagem e testes.
Um processo iterativo exige refinamento e revisão com base em feedback, testes ou reflexão ao longo de todo o processo. Isso pode exigir voltar a fases anteriores. Na linha de baixo, o programa inteiro existe desde a primeira passagem, de forma preliminar; cada rodada de feedback (vermelho) o manda de volta, e todas as partes saem mais completas.
Um processo incremental divide o problema em partes menores e garante que cada parte funcione antes de acrescentá-la ao todo. Na linha de cima, uma parte é construída e testada por vez e só se junta ao todo quando passa no teste.
Os dois não são opostos. A maioria das equipes faz ambos: constrói parte por parte e revisa cada parte, e o todo, conforme chega o feedback.
requisitos, especificação, storyboard, módulos
O projeto de um programa começa com a investigação, para determinar seus requisitos.
A investigação identifica as restrições do programa e as preocupações e interesses das pessoas que vão usá-lo. Ela pode ser feita por surveys, testes com usuários, interviews and observações diretas.
Os requisitos do programa descrevem como um programa funciona e podem incluir uma descrição das interações com o usuário que ele deve oferecer. A especificação de um programa define seus requisitos. Para um aplicativo hipotético que reserva salas de estudo de uma biblioteca: (1) o usuário escolhe uma data; (2) o usuário vê as salas livres naquele dia; (3) o usuário reserva uma e recebe um código.
A fase de projeto descreve como cumprir a especificação. Ela pode incluir:
A figura desenha duas delas: um storyboard da interface, uma tela por etapa, com o toque do usuário levando de uma tela à outra; e o programa organizado em módulos, um por requisito.
e o reconhecimento de código de outras pessoas
A documentação do programa é uma descrição escrita da função de um trecho de código, evento, procedimento ou programa e de como ele foi desenvolvido.
Os comentários são uma forma de documentação escrita no programa para ser lida por pessoas; eles não afetam como o programa executa. Nem todos os ambientes de programação aceitam comentários, e a folha de referência da prova não tem nenhum, então na figura a documentação de cada procedimento fica ao lado dele.
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]) devolve 7. A documentação é escrita durante todo o desenvolvimento: o cartão de average cresce junto com seu código. Ela ajuda a desenvolver e manter programas corretos, sozinho ou em equipe, porque o próximo leitor (muitas vezes quem escreveu, mais tarde) consegue ver para que serve cada parte.
É importante reconhecer qualquer trecho de código desenvolvido em colaboração ou por outra fonte. O reconhecimento pode estar na documentação do programa e deve incluir a origem ou o nome do autor original. Na figura, isEven (azul) vem de outra fonte, e seu cartão diz isso.
quando cada um se manifesta
Três programas, cada um feito para exibir todas as notas em [90, 75, 82]; cada um tem um erro.
Um erro de sintaxe é um erro no programa em que as regras da linguagem de programação não são seguidas. No primeiro programa, falta o parêntese de fechamento na linha 5. O programa não executa de forma alguma: nenhuma linha roda e nada é exibido.
Um erro em tempo de execução é um erro que ocorre durante a execução de um programa; cada linguagem de programação define seus próprios erros em tempo de execução. O segundo programa soma 1 a i antes de exibir, então exibe 75 and 82 e depois pede scores[4]. Na folha de referência, um índice menor que 1 ou maior que o tamanho da lista é um erro, e o programa termina.
Um erro de lógica é um erro no algoritmo ou programa que o faz se comportar de forma incorreta ou inesperada. O terceiro programa repete uma vez a menos. Nada o interrompe: ele executou até o fim, mas exibiu 2 de 3 notas. Só comparar a saída com a saída esperada revela o erro.
scores ← [90, 75, 82] i ← 1 REPEAT LENGTH(scores) - 1 TIMES { DISPLAY(scores[i]) i ← i + 1 } Corrigida, a linha 3 é REPEAT LENGTH(scores) TIMES.
um número fora do intervalo
Um erro de estouro (overflow) ocorre quando um computador tenta tratar um número que está fora do intervalo de valores definido.
Muitas linguagens de programação armazenam inteiros em um número fixo de bits, o que limita o intervalo de valores. Considere uma linguagem hipotética que armazena números inteiros em 4 bits: o maior que ela comporta é 1111, que é 15.
A figura conta a partir de 12. Cada passo inverte os bits que mudam. Em 15, somar 1 exige um quinto bit (16 é 10000), e o armazenamento tem apenas 4: um estouro. O que acontece depois depende da linguagem: algumas param com um erro, outras guardam os bits que cabem e seguem com um valor errado (aqui, 0).
As linguagens reais usam mais bits, então seus limites são bem maiores, mas continuam sendo limites. A linguagem da folha de referência da prova é diferente: nela, o tamanho de um inteiro é limitado apenas pela memória do computador.
entradas definidas, saídas esperadas
O teste usa entradas definidas para garantir que um algoritmo ou programa produza os resultados esperados. Quem programa usa os resultados para revisá-lo.
O requisito de um teatro hipotético: abaixo de 13, ou de 65 em diante, o ingresso custa $8; todas as outras pessoas pagam $12. O requisito é o que diz a quem testa quais entradas tentar e o que esperar de cada uma.
PROCEDURE price(age) { IF(age < 13 OR age ≥ 64) { RETURN(8) } RETURN(12) } Boas entradas de teste mostram os diferentes resultados esperados e ficam nos extremos ou logo além deles (o mínimo e o máximo) dos dados de entrada, onde os erros se concentram: aqui, 12 e 13 de cada lado de um limite, 64 e 65 de cada lado do outro, e a menor idade, 0.
| age (entrada) | esperado | real | |
|---|---|---|---|
| 0 | $8 | $8 | pass |
| 12 | $8 | $8 | pass |
| 13 | $12 | $12 | pass |
| 40 | $12 | $12 | pass |
| 64 | $12 | $8 | falha |
| 65 | $8 | $8 | pass |
O teste em 64 falha: o código diz age ≥ 64 onde o requisito quer dizer age ≥ 65, um erro de lógica. Um teste com uma idade típica, como 40, nunca o teria encontrado.
teste de mesa, visualização, depuração, exibição
Maneiras eficazes de encontrar e corrigir erros: casos de teste, teste de mesa, visualizações, depuradores e instruções de saída extras.
findMax deve devolver o maior número de uma lista. Testada com [-3, -7, -2], ela devolve 0, e não −2. Para ver por quê, quem programa acrescenta DISPLAY(max) dentro do laço (azul): uma instrução de saída extra.
PROCEDURE findMax(numList) { max ← 0 FOR EACH num IN numList { IF(num > max) { max ← num } DISPLAY(max) } RETURN(max) } Fazendo o teste de mesa, uma linha por elemento:
| num | num > max? | max depois | DISPLAY mostra |
|---|---|---|---|
| −3 | false | 0 | 0 |
| −7 | false | 0 | 0 |
| −2 | false | 0 | 0 |
max nunca muda: nenhum elemento é maior que 0. Um depurador mostra a mesma coisa pausando o programa e exibindo suas variáveis (as células da figura, uma visualização do estado dele). O erro está na linha 3: max começa em 0, que é maior que todos os elementos de uma lista só com números negativos.
A correção é max ← numList[1]: começar de um elemento da lista. Executando de novo, a saída extra mostra −3, −3, −2 e ela devolve −2. Então o DISPLAY extra é removido.
seu próprio programa e perguntas sobre ele
A tarefa de desempenho Create é este capítulo posto em prática: um programa de sua escolha, desenvolvido com o processo, a documentação e os testes de 1.1–1.4.
Você entrega três coisas no AP Digital Portfolio: o código do programa, um vídeo dele em execução e uma Referência Personalizada do Projeto (PPR). Você recebe pelo menos 9 horas de aula para ela. Seu programa deve incluir certos elementos, como listas e procedimentos.
No dia da prova vem a resposta escrita: 60 minutos, 2 questões sobre o código da sua própria PPR, que você pode ver enquanto responde.
A tarefa e a resposta escrita juntas valem 30% da nota AP; a prova de múltipla escolha (70 questões em 120 minutos) vale os outros 70%.
Assim, as questões deste capítulo voltam a aparecer sobre o seu próprio programa: qual é o propósito e a função dele, quais são suas entradas e saídas, o que você testou e com quais entradas, e que erro você encontrou e corrigiu.